La fréquence de la note résultante est simplement égale à la valeur absolue de la différence des fréquences des deux notes. Ainsi, en jouant une note et sa tierce exacte, on perçoit cette même note, mais deux octaves plus bas :
327 Hz (mi³) - 261,6 Hz (do³) = 65,4 Hz (do¹)
À noter que cela ne fonctionne que parce que les notes émises sont des harmoniques de la note résultante, donc les notes émises ne sont plus perçues individuellement en tant que telle, mais comme constituants du timbre de la note résultante.
En théorie, ça devrait aussi fonctionner avec d'autres intervalles, mais en pratique, ça ne semble fonctionner que pour la quinte et la tierce juste.
Cela me fait penser à une astuce utilisée avec certains orgues à tuyaux.
Pour économiser le coût et la place de certains des très longs tuyaux nécessités par les notes les plus graves, on utilise à la place, pour chacun d'entre eux, deux tuyaux plus courts, donc de fréquence plus élevée.
De mémoire, en jouant simultanément une note et sa quinte juste, on entend la même note, mais une octave en-dessous.
Avant que je n'utilise cette appli., j'utilisais effectivement l'utilitaire gpio en me connectant à l'ODROID via SSH. Et là, j'ai rencontré deux problèmes.
D'une part, un problème de place. Il me fallait rester à proximité de l'ordinateur avec lequel je me connectais à l'ODROID , ou du moins de l'écran et du clavier, mais je n'avais pas la place nécessaire pour poser la platine de montage et les composants. Grâce à l'appli., j'ai carrément pu me mettre dans une autre pièce, où je disposais d'une table où j'avais largement la place pour poser la platine, les composants et la tablette avec laquelle j'accédais à l'application ainsi que son support (et non, déplacer l'ordinateur dans cette pièce n'était pas une option).
Le second problème concernait les manipulations. À chaque fois que je voulais tester un branchement, il fallait faire flèche vers le haut pour rappeler la dernière commande, puis flèche gauche jusqu'à la position du numéro de broche, effacer ce numéro, mettre le nouveau, et valider, en modifiant au passage la valeur de la broche si nécessaire. Bon, ce n'est pas vraiment un problème, mais avec l'appli., une pression sur l'écran suffit pour aboutir au même résultat, ce qui est quand même plus pratique…
(je ne vois aucun intérêt au sans fil sur ce type de périphérique) !
l'utiliser depuis son canapé :p
Je confirme :-).
J'ai le modèle qui fait bluetooth, en plus de l'unifying. Je l'utilise en unifying au bureau, et en bluetooth sur ma tablette lors de mes déplacements, l'unique port USB de la tablette étant alors occupé par le clavier.
J'ai suivi exactement la même démarche pour exactement la même raison. Je me sens moins seul du coup, parce que d'habitude j'ai du mal à faire saisir l'intérêt de cette démarche.
En ce qui me concerne, c'est sur du C++ que je suis parti, au lieu de Python. Puis je me suis «amusé» à créer des bindings pour d'autres langages, vu que le C++ s'interface avec à peu prés n'importe quel langage.
Après Java, Node.js et PHP, je viens justement de m'attaquer au bindingPython.
Ce n'est pas parce que je n'utilise pas ces frameworks que je n'ai pas regardé comment ils fonctionnent. Et la manière dont ils fonctionnent ne me convenant pas, j'ai développé ma propre solution. Le cœur du toolkitAtlas (toute la partie en C++), je l'utilise régulièrement pour développer des interfaces web aux applications que je développe pour mes clients. Donc, ce toolkit n'est effectivement pas une marotte pour moi. Mais il est déjà largement rentabilisé.
Toute la partie développée pour la version 0.1.0 du toolkit pour le rendre utilisable avec autre chose que du C++, en fait, ça utilise du code qui est également utilisé en interne pour du développement à destination de mes clients. Le code en question étant encore assez récent, ce développement de la version 0.1.0 m'a permis de l'améliorer.
Par contre, le codage pour la version 0.2.0, destinée à faciliter le prototypage, ça, c'était clairement un défi technologique que je me suis lancé. À savoir, si, avec une installation d'une simple bibliothèque codée uniquement dans le langage choisi par le développeur pour développer son application (donc, pas de C++ pour le coup, ce qui facilite l'installation de la bibliothèque en question), bibliothèque se connectant à un serveur publique qui exécute la partie codée en C++ de mon toolkit, il lui était possible de lancer son application web sur sa machine de développement de manière à ce qu'elle soit accessible de tout l'internet sans qu'il ai quoi que ce soit à déployer sur un serveur distant.
J'ai pris à peu prés deux jours par langage pour développer ces bibliothèques, en améliorant au passage la partie C++ du toolkit. Et comme le résultat obtenu me semble faciliter le prototypage d'une application web d'une manière qui, à ma connaissance, n'existe pas par ailleurs, autant la mettre à disposition de tout un chacun, d'où ce journal…
Un bon prototype c'est - entre autres - un prototype qu'on peut reprendre en grande partie pour construire l'application cible.
Pas nécessairement.
Reprenons l'exemple de mon startupeur. S'il connaît Visual Basic, par exemple, il va pouvoir réaliser le prototype avec ce langage (si le binding correspondant est un jour développé, ce qui est tout à fait envisageable). Une fois sa démo faite aux investisseurs et les fonds nécessaires obtenus, il va pouvoir embaucher une équipe de développeurs qui va lui développer son application web avec les langages traditionnellement utilisés dans ce domaine.
Ça fait longtemps que je n'ai plus fait de VB, mais je suppose qu'il y a peu de chance que ce langage soit utilisé pour réaliser une application web de quelqu'envergure, donc, dans ce cas, le code du prototype ne sera pas utilisé dans l'application finale.
Du coup, dans ton modèle, si le proto rend les utilisateurs heureux et qu'on veut aller plus loin, qu'est-ce qui est réutilisable ? Ou, est-ce que de toute façon tu penses faire évoluer ton framework pour fournir à la fois une version "développement/lab/proto", et une version "prod" ?
Il y a déjà un mode PROD. Cependant, le cœur du toolkitAtlas est codé en C++ (c'est la partie qui est déportée sur le serveur distant en mode prototypage). Or, les gestionnaires de paquets des différents environnements de développement (npm pour Node.js, p. ex.), lorsqu'ils existent, ne sont pas conçus pour déployer du code natif. Du coup, l'installation du toolkitAtlas pour une utilisation en mode PROD n'est de loin pas aussi triviale que l'installation des frameworks traditionnellement utilisés pour le développement d'applications web. Ça, plus le fait que le toolkit n'est pas assez mature pour rivaliser avec ces frameworks, fait que je préfère, pour le moment, mettre en avant le mode prototypage.
Autre question. Sur le fond, j'aime bien le principe de framework tout intégré, mais à quel point ton framework est plus intégré que l'existant ? Côté Front, comment je gère la zolie interface graphique ? Côté Back, comment je me connecte à des ressources de type bus de message et base de données ?
Le toolkitAtlas n'est pas un framework ; c'est une simple bibliothèque (alias package, extension, module, addon, librairie… selon le langage utilisé) à utiliser dans le back-end. La récupération des données saisies par l'utilisateur et celle des actions qu'il effectue, la mise en forme des données à afficher dans le navigateur… tout ça se fait directement au niveau du back-end. Donc, il n'y a pas de données qui doivent être explicitement transférées du front-end au back-end et vice-versa.
Lorsque l'utilisateur réalise une action dans l'application, cette action va être directement récupérée au niveau du back-end. Si cette action nécessite l'affichage de données, celles-ci vont pouvoir être obtenues par une requête, dans le back-end, tout ce qu'il y a de plus classique au moteur de base de données. La mise en forme et l'envoi de ces données au navigateur web vont être réalisés, toujours dans le back-end, simplement par des appels aux fonctions du toolkitAtlas. Le développeur n'a plus à s'occuper du front-end en tant que tel.
Le schéma demandé relève du détail technique dont l'utilisateur ne devrait pas avoir à se préoccuper.
Quelle est ta cible d'utilisateurs, exactement ?
Je n'ai pas développé ce toolkit en ayant un type d'utilisateur en tête. Maintenant, ce qui me vient à l'esprit, à froid, c'est le cas celui qui veut monter une startup, puisque c'est à la mode.
Beaucoup de startups s'appuient sur un service web. La première préoccupation du startupeur, c'est de convaincre des financeurs. S'il a quelques compétences en matière de développement, ou qu'il a sous la main quelqu'un qui a de telles compétences, quelque que soit le langage, il va pouvoir rapidement développer ou faire développer un prototype de son application grâce au toolkitAtlas.
Le jour où il va aller présenter son idée de startup pour obtenir des financements, il va à son RDV avec son ordinateur portable sous le bras, il passe quelque slides pour présenter son idée, et, au lieu de présenter des captures écrans de ce à quoi va ressembler sa future application, il va lancer le prototype de cette application directement sur son ordinateur portable (sous réserve qu'il soit connecté à internet), et la manipuler sous les yeux des décideurs. Et, s'il le décide, il peut afficher le code QR de l'application, et ainsi les décideurs pourront eux-mêmes manipuler l'application sur leur smartphone/tablette/ordinateur portable. Rien n'est de trop lorsqu'il s'agit de convaincre des investisseurs…
En tant que développeur de métier, le contexte dans lequel mon application est exécutée est une des premières choses que je vais regarder. L’environnement de l’application a toujours un impact, plus ou moins important, sur celle-ci.
Dans le cas d'atlas, qu'est-ce qui se passe si je tente d'accéder à des fichiers distants ? À des fichiers présente sur le réseau local de ma machine ? Est-ce qu'il est possible d'ouvrir des ports réseaux supplémentaires ? Est-ce compatible avec un support des websockets ?
L'idée de base du toolkitAtlas, c'est que les manipulations du DOM qui ne sont généralement réalisables qu'en JavaScript, et donc dans le front-end, soient disponibles dans le back-end, et ce dans le langage utilisé pour programmer ce dernier, quelque soit ce langage. Le code HTML qui est envoyé dans le navigateur peut, sans problème, contenir du code JavaScript. Le toolkitAtlas n'offre que la possibilité de manipuler le DOM à partir du back-end. Tout le reste peut se réaliser de manière classique.
le toolkitAtlas n'en est qu'à ses débuts, et je ne sais pas comment il se positionne par rapport à des solutions de développement web classiques (je n'ai jamais utilisé de telles solutions). C'est pour cela qu'en attendant qu'il soit suffisamment mature, sous réserve que les choix techniques retenus pour ce toolkit le permette, pour rivaliser avec les solutions existantes, je le présente comme une solution de prototypage, en mettant en avant une facilité de déploiement qui, me semble-t-il, n'est offerte par aucune autre solution de développement d'applications web.
Cependant, en mode prototypage, le toolkitAtlas présente certaines limitations, et les fonctionnalités avancées de certaines solutions de développement d'applications web ne sont pas disponibles avec le toolkitAtlas. Mais, d'un autre coté, on a rarement besoin de fonctionnalités avancées pour un prototype. En outre, il est bien entendu possible que certaines de ces fonctionnalités puisse être disponibles dans les futures versions du toolkit…
Il ne faut pas perdre de vue que, en l'état, le toolkit n'est prévu que pour réaliser du prototypage, donc, à priori, l'application finale n'utilisera pas ce toolkit, rendant, il me semble, ce genre de questionnement superflu.
Cependant, pour répondre rapidement à la question, en attendant l'éventuelle publication de la dépêche, je peux indiquer les différents composants constituant ce toolkit et leurs répartitions :
Alors, sur la machine du développeur, voilà ce qui tourne (il y des sources C++ dans les repositories, mais ils ne sont pas utilisés dans ce mode de fonctionnement du toolkit) :
Et, sur le serveur distant, celui qui est mis à disposition gracieusement, il y un serveur apache, qui relaie les requêtes du navigateur web de l'utilisateur vers ce logiciel : https://github.com/epeios-q37/xdhwebq-cli. Ce logiciel se connecte à cet autre logiciel : https://github.com/epeios-q37/xdhq. C'est également à ce dernier logiciel que se connecte la partie du toolkit installée sur la machine du développeur.
Bon, je vais quand même tenter un schéma :
Machine util. Serveur distant Machine développeur
------------ ----------------------------------- ----------------------
| nav. web | --> | apache --> xdhwebq-cli --> xdhq | <-- | xdhq-.../atlas-... |
------------ ----------------------------------- ----------------------
Signification de la flèche :
client --> serveur
D'une part, cela dépend du mode de fonctionnement choisi. D'autre part, le mode de fonctionnement décrit dans ce journal, qui est maintenant le mode de fonctionnement par défaut, a justement été conçu pour que l'utilisateur n'ai pas à se préoccuper de cela. Il installe le toolkit, il code son prototype, il le lance, et ça fonctionne. Il n'a pas à se demander s'il faut un serveur http, si un tel serveur est inclut dans le toolkit, s'il faut une machine qui soit accessible d'internet, et, le cas échéant, qu'est-ce qui doit être installé sur cette machine, etc.
L'idée c'est d'avoir un outil qui soit le plus simple possible à mettre en œuvre, d'où la diversité (parmi trois seulement aujourd'hui, en attendant de futurs développements) de langages utilisables, et le fait qu'il suffise d'un ordinateur connecté à internet pour que le prototype soit accessible partout depuis internet. Plus c'est simple à utiliser, plus important sera le nombre d'utilisateur.
Le schéma demandé relève du détail technique dont l'utilisateur ne devrait pas avoir à se préoccuper. Par contre, ce schéma intéressera un éventuel contributeur, mais avant d'avoir des contributeurs, il faut des utilisateurs, c'est pour ça que je pensais aborder les détails techniques dans un second temps seulement.
Ceci dit, si, comme semble le suggérer la note du commentaire, ce schéma intéresse un nombre suffisant de personnes, il pourra être inclut, avec éventuellement d'autres éléments techniques semblables, dans la dépêche qu'on me suggère de rédiger dans les précédents commentaires…
Une dépêche ? Je veux bien tenter l'expérience. Mais il faudra m'indiquer précisément quel devra en être le contenu attendu, pour que je puisse en rédiger un premier jet qui soit plus parlant au lectorat de ce site que le contenu de ce journal. Premier jet que je modifierais en fonction des différentes suggestions jusqu'à aboutir à un contenu qui fasse consensus (je suppose que c'est le principe de fonctionnement de l'espace collaboratif).
Dans le même temps, le sous système linux a des gros inconvénients :
[…]
- on est root d'office dans le sous système linux, […]
Négatif ! Il faut faire un sudo pour pouvoir faire un aptitude update, par exemple.
le terminal est un cmd, donc pas très configurable
Pas sûr que ça s'oppose à ton affirmation, mais on peut le lancer dans conEmu, par exemple,
il faut penser à lancer la commande bash à chaque fois qu'on veut un terminal (c'est là aussi qu'on perd du temps entre le démarrage du cmd et de bash ensuite)
Là aussi, pas sûr que ça s'oppose à ton affirmation, mais on peut le lancer à partir d'une icône.
Quand je me suis intéressé au développement d'interfaces natives, j'ai consulté la doc. et les tutos, pas de manière très approfondie, il est vrai, de toolkits comme Qt, wxWidgets, qui devait encore s'appeler wxWindows à l'époque, et d'autres dont je ne me souviens plus du nom. Or, je ne me souviens pas qu'il y soit jamais fait référence à MVC. Peut-être que je n'ai pas poussé ma lecture assez loin.
Lorsque je me suis intéressé au développement d'interfaces web, j'ai également consulté la doc. et les tutos de différents framework, et là, il y est rapidement fait référence à MVC. Et pourtant, je n'ai pas l'impression d'avoir pousser ma lecture plus loin qu'avec les docs et tutos ci-dessus, d'où ma méprise.
PS: L'échappement des inputs web c'est pas quelque chose qui se gère en trois lignes, les règles changent en fonction du contexte.
C'est vraiment juste un truc que j'ai codé en mode quick and dirty, pour gérer les cas les plus évidents (&, <, "…).
Le plus gros soucis avec l'utilisation de C++ pour la gestion d'interface Web a mon sens n'a rien a voir avec le language, mais tout a voir avec le fait que comme très peu de personnes l'utilisent dans ce but, tout l'ecosystème de la sécurité web va être à refaire …
Oui, c'est possible. D'un autre coté, vu le nombre d'outils qui existent pour faire du développement web dans d'autres langages, il y en a probablement pas mal qui ont une licence suffisamment permissive pour pouvoir s'en inspirer, voire carrément copier le code concerné, puisque pas mal de ces langages sont codés en interne en C ou en C++…
Non tu affirme que c'est peu utilisé en natif (tu as même tenté de dire que ce n'était pas très populaire, ce qui est drôle quand on est seul utilisateur d'une techno). Je te pointe des documents qui montent que c'est une notion centrale de bibliothèques très utilisées
Possible que je me sois gouré sur sur son degré d'utilisation mais j'aimerais quand même un lien sur une appli avec interface native qui utilise MVC et dont je peux voir les sources, et, vu ce que tu dis des documents dont tu m'as donné la référence, ça ne devrait pas être très difficile à produire…
Et je ne vois pas en quoi croire (même si, à priori, à tort) qu'une techno. n'est pas très utilisée, c'est la critiquer.
Tu fais sincèrement ce que tu veux. Je m'en fou. C'est juste que tu remplace un pattern d'archi utilisé par aucun. Dans le monde argument. C'est juste dommage parce que tu nous dis à côté ne pas être capable de rester ton code. MVC est entre autre là pour que tu puisse le faire.
J'ai mon propre pattern d'archi, et je n'ai jamais dit que je n'étais pas capable de tester mon code, juste qu'écrire le code correspondant n'est, actuellement, pour moi, pas économiquement viable. Et, à l'instar de MVC, mon propre pattern d'archi est tout à fait adapté à l'écriture de tests, mais écrire le code de ces tests… (etc.).
Parce que ton code est bugué? Fais ce que tu veux mais ton code est bugué si tu ne te débrouilles pas pour que ça fonctionne avant de te lancer dans des trucs fous comme une structure commerciale tu va dans le mur. Il n'y a pas de "mais ça fonctionnait", il faut mettre en place quelque chose pour s'assurer que ce que tu sors fonctionne. Tu veux pas faire de test unitaire très bien, il y a avoir un cahier de test, hier sur un environnement propre (docker ou une vm par exemple), etc. Pour le moment tu ne semble pas prendre conscience du problème. Avec ou sans communication ton truc ne fonctionne pas. Je l'ai ressayé, ça a "marchait" quelques fois (avoir des erreurs et servir lancer le programme au debuger pour trouver l'url qui va bien, c'est fonctionner ?). Puis plus du tout, comme si ton serveur ne répondait de token à mon client… J'ai pas de doute que ça se corrige mais il faut que tu attrape ce genre de problème plus tôt si tu veux rester crédible. Si les gens doivent payer les pots casser à chaque nouvelle version, ils ne peuvent qu'aller voir ailleurs, tu ne leur donne pas le choix.
faire des tests sur un code ne garantit pas qu'il est exempt de bugs,
concernant le bug que tu as rencontré, tests ou pas tests, ça ne change rien, parce que je n'arrive pas à reproduire le problème (ceci dit, je suis en train de travailler sur une nouvelle version de Atlas.jar qui corrige ce bug, mais ça sera évidemment une correction à l'aveugle),
faire des tests sur un code ne garantit pas qu'il est exempt de bugs (oui, c'est la même chose que le 1., mais ça s'applique également au second bug que tu as rencontré).
Bref, rien ne prouve que tu n'aurais pas rencontré les mêmes problèmes avec mon appli. si je l'avais soumise à une batterie de tests que j'aurais codés. Je ne nie pas que ce soit possible, mais, de mon expérience, j'en estime la probabilité très faible, trop faible pour que j'investisse du temps (et donc de l'argent) pour pallier à cet hypothétique problème en codant des tests.
Je ne te convaincrais pas, tu ne me convaincras pas, donc je propose d'en rester là sur le sujet. Et cette proposition vaut aussi pour les autres qui seraient tenté d'intervenir sur ce même sujet.
M'ignorer ? Si l'alternative c'est d'avoir à répondre à des commentaires hors sujet et/ou contenant des arguments d'une part erronés et qui, d'autre part, ne font pas avancer le débat, oui, je préfère.
mais tu ne vas probablement rien comprendre, parce que j'utilise un framework maison, et pas seulement pour la partie web. C'est pour ça que je n'en parle pas.
Les bindingsJava, Node.js, PHP… permettent de faire abstraction de ce framework.
Regarde ce que font Microsoft, Apple et google si tu me crois pas.
je pensais qu'il faisait référence à des applications natives développées par Microsoft, Apple, Google, whoever…, qui s'appuient sur MVC et dont les sources sont consultables. C'est ça qui m'intéresse.
En outre, lorsqu'on clique sur le premier lien, il y a ça qui s'affiche :
Retired Document
Important: This document may not represent best practices for current development. Links to downloads and other resources may no longer be valid.
Pour le reste :
Depuis quand ne pas utiliser une techno (ne pas mettre en œuvre une pratique), c'est critiquer cette techno (pratique) ?
Je n'ai aucun problème avec les personnes qui utilisent MVC. Pourquoi donc y a-t-il des personnes pour qui cela représente un problème que, moi, je ne l'utilise pas ?
Je n'ai aucun problème avec les personnes qui codent des tests auxquels ils soumettent leur code, d'autant moins que c'est même une pratique que j'ai maintes et maintes fois encouragée. Pourquoi donc y a-t-il des personnes à qui ça pose un tel problème que, moi, je ne code pas de tels tests, au point d'en déformer mes propos sur le sujet ?
Ces personnes me font de plus en plus penser à ça :
La seule raison que je puisse donner pour utiliser cette bibliothèque, c'est celle qui m'a motivée à la développer, c'est-à-dire pouvoir coder l'intégralité d'une application web en C++. Sauf, et je pense que l'ensemble des commentaires de ce journal l'ont clairement établit, que peu de personnes utiliseront cette bibliothèque pour cette raison. Au contraire même, le fait qu'il faille faire du C++ pour l'utiliser serait même plutôt, pour beaucoup de personnes, une raison de ne pas l'utiliser. Je ne critique pas, je constate. Du coup, je me suis bien gardé d'avancer cette raison.
Avant de me lancer dans son développement, j'ai regardé ce qui existait, et j'ai constaté que beaucoup d'outils s'appuyaient sur MVC. J'ai regardé ce dont il s'agissait, et je n'en pas vu l'intérêt, sachant que ça fait des années que je développe des interfaces natives sans avoir à m'appuyer sur MVC. Là aussi, apparemment, je fais figure d'exception, semble-t-il, vu que, selon certains commentaires, MVC semble être aussi la norme en matière d'interfaces natives.
Bref, n'ayant jamais utilisé l'un de ces outils basé sur MVC, je serais bien en peine d'avancer ne fût-ce qu'une raison qui pourrait pousser quelqu'un à délaisser son outil au profit de ma bibliothèque, et ce malgré tous les bindings que je pourrais réaliser pour faciliter l'accès à cette bibliothèque. C'est malheureux, mais c'est ainsi. En outre, ces personnes seront d'autant plus réticent qu'il leur a certainement fallu pas mal de temps pour maîtriser l'outil qu'ils utilisent. Il faudra donc de sacrées bonnes raisons pour les pousser à faire une croix sur cet investissement au profit de ma bibliothèque…
Clairement, Le gros problème de ce projet, c'est moi. Ça lui serait nettement plus bénéfique si je pouvais me cantonner à l'aspect technique, et laisser quelqu'un de plus doué que moi en communication en faire la promotion. Sauf que, pour l'instant, je suis seul sur ce projet, et donc, je fais avec. Donc, je communique tant bien que mal, apparemment plutôt mal que bien, sachant qu'il est toujours préférable de mal communiquer que de ne pas communiquer du tout !
Je ne sais plus si c'est dans ce journal ou l'autre que j'en parle, mais j'ai le projet d'animer des ateliers autour de cette bibliothèque. Le fait qu'elle soit disponible en plusieurs langages et simple à installer, combiné au fait qu'elle permet de manipuler, sans artifices particuliers, les concepts de base des technos web, à savoir HTML, CSS et DOM, je pense que cette bibliothèque est un bon outil d'initiation à ces concepts. J'ignore si ces ateliers seront, par ailleurs, profitables à ma bibliothèque, mais, là encore, mieux vaut faire ces ateliers que de ne rien faire du tout…
Ce n'est pas parce que les plus gros l’utilisent que c'est la norme…
Plus précisément, je ne me rappelle pas avoir jamais vu quoique ce soit de relatif au MVC dans les codes d'application natifs que j'ai pu voir, ni dans les tutoriaux des différents toolkits (s'ils l'abordent, ça doit vraiment être dans les chapitres les plus avancés)…
Mais ça m'intéresse de voir comment c'est mis en œuvre. Tu parles de quoi exactement quand tu me suggères de regarder ce que font Microsoft, Apple et google ?
Ce chapitre ne te concerne pas personnellement (d'où le vouvoiement, alors que j'ai utilisé le tutoiement pour m'adresser à toi juqu'à présent). C'est juste un résumé de l'objectif du journal, à l'intention de tout ceux qui liraient ce commentaire et pour qui cela ne serait pas clair.
J'avais prévenu que je n'y connaissais pas grand chose en Java !
[…]
je préviens d'avance, je ne m'y connais pas plus en PHP qu'en Java).
Mais si tu n'y connais rien, pourquoi tu te tapes les bindings toi-même ? Tu sais que tu vas avoir des versions toutes bancales qui feront peur plus qu'elles donneront envie. Si tu as une lib libre de qualité en C++, tu ne devrais avoir aucun mal à convaincre des développeurs plus expérimentés de faire les bindings dans les langages qui les intéressent.
Oui mais, aussi bancal que ce soit, c'est toujours plus facile que d'avoir à partir de zéro. En outre, aussi expérimenté que soit le développeur, je doute qu'il y en ai beaucoup qui sachent interfacer du PHP avec du C++, mais je me trompe peut-être…
Ceci dit, pour le coup, j'ai peut-être une connaissance faisant du PHP qui pourra m'aider…
Pour le reste, dans l'ordre :
Tu ne mets pas 2 classes de premier niveau dans le même fichier en Java. C'est techniquement possible, mais personne ne fait ça.
Soit.
Il n'y a pratiquement aucune raison de faire new String() en Java. En fait, je n'en vois aucune.
En fait, si je comprend bien en faisant [String] tata = "tutu;", le new est fait automatiquement, c'est cela ?
Il n'y a aucun problème à utiliser un champ dans une méthode.
Dans tous les cas, une variable locale ne devrait jamais avoir le même nom qu'un champ – j'imagine que c'est la même chose en C++ ?
Franchement, je ne vois pas le problème, mais bon…
L'itérateur, c'est Java 5 (2004).
OK, je n'aurais donc aucun scrupule à l'utiliser.
Aucun intérêt à faire du Java < 8 en 2018 sur un nouveau projet.
OK.
On ne commite pas les if de test, ou alors on les commente – j'imagine que c'est la même chose en C++ ?
OK ! Pas taper ! Je vais mettre un commentaire !
Tu as bien compris pour le new.
Super !
Un code de démo doit être le plus clair possible et illustrer les bonnes pratiques. Si c'est plus clair avec 15 fichiers qu'avec un seul, alors ça doit être dans 15 fichiers – j'imagine que c'est la même chose en C++ ?
Sauf qu'en C++, le compilateur n'impose jamais une correspondance entre le nom d'un fichier et son contenu, donc on est plus facilement tenté de d'accumuler les classes dans un seul et même fichier (je ne dis pas que c'est une bonne chose !)
On ne peut pas « nuller » un type primitif, mais il y a les classes enveloppes (pour toi Integer) pour ça. Depuis Java 5 (2004) le boxing et l'unboxing (conversion classes enveloppes ↔ types primitifs) sont automatiques.
Je connaissais les Integer, je les utilise dans certains contextes, mais là il me semblait plus pertinent d'utiliser un int, pensant, sans doute à tord, que c'est plus léger qu'un Integer.
Le code que j'ai proposé pour le paramètre xml fonctionne normalement depuis Java 1.0.
Et je vais l'adopter.
Ton explication sur les triples négations n'enlève rien au fait que c'est une triple négation. Pour des raisons de lisibilité (et sauf cas très exceptionnel), un if/else à branches équilibrées (ici c'est le cas) devrait être de la forme if (a == b) { X() } else { Y() } et non if (a != b) { Y() } else { X() }. Et les actions devraient avoir un sens positif (ShowBidule) et pas négatif (HideBidule). C'est valable dans tous les langages, dont le C++.
L'une comme l'autre forme me convienne parfaitement, mais si ça peut faciliter la lecture à certains…
Par contre, le ShowBidule/HideBidule, faut voir, car ce sont des identifiant d'éléments de style, et ça risque de les alourdir.
Un code qui n'est pas un pur test devrait utiliser un logger (y'en a un dans l'API standard).
S'il n'y a effectivement rien à installer de plus, je vais probablement l'utiliser.
Un lien clé-valeur en Java, c'est une Map…
OK. Je vais voir ça.
J'ai essayé de le tester. J'ai eu le même genre d'emmerdes que barmic dans ce commentaire, sauf que moi j'ai écris mon retour sur ma pause au boulot. Je n'avais pas 1h à passer pour faire marcher le bordel.
Et tu as lancé le bordel dans un environnement sans interface graphique ? Je subodore que c'est ce qui est arrivé à barmic, mais je n'en ai pas la confirmation…
Tu peux tenter de pousser une Poule Request sur un projet open source qui te tente.
Franchement, vu mon niveau en Java, ça ne va sans doute pas le faire. En outre, j'ai déjà bien assez à faire avec mes propres projets open source. Et j'ai déjà pas mal de grain à moudre avec les commentaires de ce journal.
Merci pour les pointeurs. N'étant pas omniscient, ça ne fait pas de doute que j'y apprendrais des choses…
[^] # Re: Orgues à tuyaux
Posté par Claude SIMON (site web personnel) . En réponse au message Expérience d’interférences. Évalué à 2. Dernière modification le 14 février 2019 à 08:32.
La fréquence de la note résultante est simplement égale à la valeur absolue de la différence des fréquences des deux notes. Ainsi, en jouant une note et sa tierce exacte, on perçoit cette même note, mais deux octaves plus bas :
327 Hz (mi³) - 261,6 Hz (do³) = 65,4 Hz (do¹)
À noter que cela ne fonctionne que parce que les notes émises sont des harmoniques de la note résultante, donc les notes émises ne sont plus perçues individuellement en tant que telle, mais comme constituants du timbre de la note résultante.
En théorie, ça devrait aussi fonctionner avec d'autres intervalles, mais en pratique, ça ne semble fonctionner que pour la quinte et la tierce juste.
Zelbinium: Your Devices, Your Rules!
# Orgues à tuyaux
Posté par Claude SIMON (site web personnel) . En réponse au message Expérience d’interférences. Évalué à 3.
Cela me fait penser à une astuce utilisée avec certains orgues à tuyaux.
Pour économiser le coût et la place de certains des très longs tuyaux nécessités par les notes les plus graves, on utilise à la place, pour chacun d'entre eux, deux tuyaux plus courts, donc de fréquence plus élevée.
De mémoire, en jouant simultanément une note et sa quinte juste, on entend la même note, mais une octave en-dessous.
Zelbinium: Your Devices, Your Rules!
[^] # Re: Chrome ou Firefox
Posté par Claude SIMON (site web personnel) . En réponse au message "Unresponsive script" : limiter Firefox. Évalué à 3.
https://developer.mozilla.org/fr/docs/Chrome
Zelbinium: Your Devices, Your Rules!
[^] # Re: Le problème est où ?
Posté par Claude SIMON (site web personnel) . En réponse au journal Application web de contrôle des GPIOs d'un Raspberry Pi/ODROID-C2. Évalué à 1. Dernière modification le 19 décembre 2018 à 17:51.
Avant que je n'utilise cette appli., j'utilisais effectivement l'utilitaire
gpioen me connectant à l'ODROID via SSH. Et là, j'ai rencontré deux problèmes.D'une part, un problème de place. Il me fallait rester à proximité de l'ordinateur avec lequel je me connectais à l'ODROID , ou du moins de l'écran et du clavier, mais je n'avais pas la place nécessaire pour poser la platine de montage et les composants. Grâce à l'appli., j'ai carrément pu me mettre dans une autre pièce, où je disposais d'une table où j'avais largement la place pour poser la platine, les composants et la tablette avec laquelle j'accédais à l'application ainsi que son support (et non, déplacer l'ordinateur dans cette pièce n'était pas une option).
Le second problème concernait les manipulations. À chaque fois que je voulais tester un branchement, il fallait faire flèche vers le haut pour rappeler la dernière commande, puis flèche gauche jusqu'à la position du numéro de broche, effacer ce numéro, mettre le nouveau, et valider, en modifiant au passage la valeur de la broche si nécessaire. Bon, ce n'est pas vraiment un problème, mais avec l'appli., une pression sur l'écran suffit pour aboutir au même résultat, ce qui est quand même plus pratique…
Zelbinium: Your Devices, Your Rules!
[^] # Re: très bien
Posté par Claude SIMON (site web personnel) . En réponse au message vendu. Évalué à 1.
Je confirme :-).
J'ai le modèle qui fait bluetooth, en plus de l'unifying. Je l'utilise en unifying au bureau, et en bluetooth sur ma tablette lors de mes déplacements, l'unique port USB de la tablette étant alors occupé par le clavier.
Zelbinium: Your Devices, Your Rules!
[^] # Re: compilation
Posté par Claude SIMON (site web personnel) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 3.
J'ai suivi exactement la même démarche pour exactement la même raison. Je me sens moins seul du coup, parce que d'habitude j'ai du mal à faire saisir l'intérêt de cette démarche.
En ce qui me concerne, c'est sur du C++ que je suis parti, au lieu de Python. Puis je me suis «amusé» à créer des bindings pour d'autres langages, vu que le C++ s'interface avec à peu prés n'importe quel langage.
Après Java, Node.js et PHP, je viens justement de m'attaquer au binding Python.
Zelbinium: Your Devices, Your Rules!
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 0.
Ce n'est pas parce que je n'utilise pas ces frameworks que je n'ai pas regardé comment ils fonctionnent. Et la manière dont ils fonctionnent ne me convenant pas, j'ai développé ma propre solution. Le cœur du toolkit Atlas (toute la partie en C++), je l'utilise régulièrement pour développer des interfaces web aux applications que je développe pour mes clients. Donc, ce toolkit n'est effectivement pas une marotte pour moi. Mais il est déjà largement rentabilisé.
Toute la partie développée pour la version 0.1.0 du toolkit pour le rendre utilisable avec autre chose que du C++, en fait, ça utilise du code qui est également utilisé en interne pour du développement à destination de mes clients. Le code en question étant encore assez récent, ce développement de la version 0.1.0 m'a permis de l'améliorer.
Par contre, le codage pour la version 0.2.0, destinée à faciliter le prototypage, ça, c'était clairement un défi technologique que je me suis lancé. À savoir, si, avec une installation d'une simple bibliothèque codée uniquement dans le langage choisi par le développeur pour développer son application (donc, pas de C++ pour le coup, ce qui facilite l'installation de la bibliothèque en question), bibliothèque se connectant à un serveur publique qui exécute la partie codée en C++ de mon toolkit, il lui était possible de lancer son application web sur sa machine de développement de manière à ce qu'elle soit accessible de tout l'internet sans qu'il ai quoi que ce soit à déployer sur un serveur distant.
J'ai pris à peu prés deux jours par langage pour développer ces bibliothèques, en améliorant au passage la partie C++ du toolkit. Et comme le résultat obtenu me semble faciliter le prototypage d'une application web d'une manière qui, à ma connaissance, n'existe pas par ailleurs, autant la mettre à disposition de tout un chacun, d'où ce journal…
Zelbinium: Your Devices, Your Rules!
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 1. Dernière modification le 07 septembre 2018 à 15:47.
Pas nécessairement.
Reprenons l'exemple de mon startupeur. S'il connaît Visual Basic, par exemple, il va pouvoir réaliser le prototype avec ce langage (si le binding correspondant est un jour développé, ce qui est tout à fait envisageable). Une fois sa démo faite aux investisseurs et les fonds nécessaires obtenus, il va pouvoir embaucher une équipe de développeurs qui va lui développer son application web avec les langages traditionnellement utilisés dans ce domaine.
Ça fait longtemps que je n'ai plus fait de VB, mais je suppose qu'il y a peu de chance que ce langage soit utilisé pour réaliser une application web de quelqu'envergure, donc, dans ce cas, le code du prototype ne sera pas utilisé dans l'application finale.
Il y a déjà un mode PROD. Cependant, le cœur du toolkit Atlas est codé en C++ (c'est la partie qui est déportée sur le serveur distant en mode prototypage). Or, les gestionnaires de paquets des différents environnements de développement (npm pour Node.js, p. ex.), lorsqu'ils existent, ne sont pas conçus pour déployer du code natif. Du coup, l'installation du toolkit Atlas pour une utilisation en mode PROD n'est de loin pas aussi triviale que l'installation des frameworks traditionnellement utilisés pour le développement d'applications web. Ça, plus le fait que le toolkit n'est pas assez mature pour rivaliser avec ces frameworks, fait que je préfère, pour le moment, mettre en avant le mode prototypage.
Le toolkit Atlas n'est pas un framework ; c'est une simple bibliothèque (alias package, extension, module, addon, librairie… selon le langage utilisé) à utiliser dans le back-end. La récupération des données saisies par l'utilisateur et celle des actions qu'il effectue, la mise en forme des données à afficher dans le navigateur… tout ça se fait directement au niveau du back-end. Donc, il n'y a pas de données qui doivent être explicitement transférées du front-end au back-end et vice-versa.
Lorsque l'utilisateur réalise une action dans l'application, cette action va être directement récupérée au niveau du back-end. Si cette action nécessite l'affichage de données, celles-ci vont pouvoir être obtenues par une requête, dans le back-end, tout ce qu'il y a de plus classique au moteur de base de données. La mise en forme et l'envoi de ces données au navigateur web vont être réalisés, toujours dans le back-end, simplement par des appels aux fonctions du toolkit Atlas. Le développeur n'a plus à s'occuper du front-end en tant que tel.
Zelbinium: Your Devices, Your Rules!
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 2. Dernière modification le 07 septembre 2018 à 11:39.
Je n'ai pas développé ce toolkit en ayant un type d'utilisateur en tête. Maintenant, ce qui me vient à l'esprit, à froid, c'est le cas celui qui veut monter une startup, puisque c'est à la mode.
Beaucoup de startups s'appuient sur un service web. La première préoccupation du startupeur, c'est de convaincre des financeurs. S'il a quelques compétences en matière de développement, ou qu'il a sous la main quelqu'un qui a de telles compétences, quelque que soit le langage, il va pouvoir rapidement développer ou faire développer un prototype de son application grâce au toolkit Atlas.
Le jour où il va aller présenter son idée de startup pour obtenir des financements, il va à son RDV avec son ordinateur portable sous le bras, il passe quelque slides pour présenter son idée, et, au lieu de présenter des captures écrans de ce à quoi va ressembler sa future application, il va lancer le prototype de cette application directement sur son ordinateur portable (sous réserve qu'il soit connecté à internet), et la manipuler sous les yeux des décideurs. Et, s'il le décide, il peut afficher le code QR de l'application, et ainsi les décideurs pourront eux-mêmes manipuler l'application sur leur smartphone/tablette/ordinateur portable. Rien n'est de trop lorsqu'il s'agit de convaincre des investisseurs…
L'idée de base du toolkit Atlas, c'est que les manipulations du DOM qui ne sont généralement réalisables qu'en JavaScript, et donc dans le front-end, soient disponibles dans le back-end, et ce dans le langage utilisé pour programmer ce dernier, quelque soit ce langage. Le code HTML qui est envoyé dans le navigateur peut, sans problème, contenir du code JavaScript. Le toolkit Atlas n'offre que la possibilité de manipuler le DOM à partir du back-end. Tout le reste peut se réaliser de manière classique.
le toolkit Atlas n'en est qu'à ses débuts, et je ne sais pas comment il se positionne par rapport à des solutions de développement web classiques (je n'ai jamais utilisé de telles solutions). C'est pour cela qu'en attendant qu'il soit suffisamment mature, sous réserve que les choix techniques retenus pour ce toolkit le permette, pour rivaliser avec les solutions existantes, je le présente comme une solution de prototypage, en mettant en avant une facilité de déploiement qui, me semble-t-il, n'est offerte par aucune autre solution de développement d'applications web.
Cependant, en mode prototypage, le toolkit Atlas présente certaines limitations, et les fonctionnalités avancées de certaines solutions de développement d'applications web ne sont pas disponibles avec le toolkit Atlas. Mais, d'un autre coté, on a rarement besoin de fonctionnalités avancées pour un prototype. En outre, il est bien entendu possible que certaines de ces fonctionnalités puisse être disponibles dans les futures versions du toolkit…
Zelbinium: Your Devices, Your Rules!
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 4. Dernière modification le 07 septembre 2018 à 10:15.
Il ne faut pas perdre de vue que, en l'état, le toolkit n'est prévu que pour réaliser du prototypage, donc, à priori, l'application finale n'utilisera pas ce toolkit, rendant, il me semble, ce genre de questionnement superflu.
Cependant, pour répondre rapidement à la question, en attendant l'éventuelle publication de la dépêche, je peux indiquer les différents composants constituant ce toolkit et leurs répartitions :
Alors, sur la machine du développeur, voilà ce qui tourne (il y des sources C++ dans les repositories, mais ils ne sont pas utilisés dans ce mode de fonctionnement du toolkit) :
Et, sur le serveur distant, celui qui est mis à disposition gracieusement, il y un serveur apache, qui relaie les requêtes du navigateur web de l'utilisateur vers ce logiciel : https://github.com/epeios-q37/xdhwebq-cli. Ce logiciel se connecte à cet autre logiciel : https://github.com/epeios-q37/xdhq. C'est également à ce dernier logiciel que se connecte la partie du toolkit installée sur la machine du développeur.
Bon, je vais quand même tenter un schéma :
Zelbinium: Your Devices, Your Rules!
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 2.
D'une part, cela dépend du mode de fonctionnement choisi. D'autre part, le mode de fonctionnement décrit dans ce journal, qui est maintenant le mode de fonctionnement par défaut, a justement été conçu pour que l'utilisateur n'ai pas à se préoccuper de cela. Il installe le toolkit, il code son prototype, il le lance, et ça fonctionne. Il n'a pas à se demander s'il faut un serveur http, si un tel serveur est inclut dans le toolkit, s'il faut une machine qui soit accessible d'internet, et, le cas échéant, qu'est-ce qui doit être installé sur cette machine, etc.
L'idée c'est d'avoir un outil qui soit le plus simple possible à mettre en œuvre, d'où la diversité (parmi trois seulement aujourd'hui, en attendant de futurs développements) de langages utilisables, et le fait qu'il suffise d'un ordinateur connecté à internet pour que le prototype soit accessible partout depuis internet. Plus c'est simple à utiliser, plus important sera le nombre d'utilisateur.
Le schéma demandé relève du détail technique dont l'utilisateur ne devrait pas avoir à se préoccuper. Par contre, ce schéma intéressera un éventuel contributeur, mais avant d'avoir des contributeurs, il faut des utilisateurs, c'est pour ça que je pensais aborder les détails techniques dans un second temps seulement.
Ceci dit, si, comme semble le suggérer la note du commentaire, ce schéma intéresse un nombre suffisant de personnes, il pourra être inclut, avec éventuellement d'autres éléments techniques semblables, dans la dépêche qu'on me suggère de rédiger dans les précédents commentaires…
Zelbinium: Your Devices, Your Rules!
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 2.
Une dépêche ? Je veux bien tenter l'expérience. Mais il faudra m'indiquer précisément quel devra en être le contenu attendu, pour que je puisse en rédiger un premier jet qui soit plus parlant au lectorat de ce site que le contenu de ce journal. Premier jet que je modifierais en fonction des différentes suggestions jusqu'à aboutir à un contenu qui fasse consensus (je suppose que c'est le principe de fonctionnement de l'espace collaboratif).
Zelbinium: Your Devices, Your Rules!
[^] # Re: Eeeuuuhhhh
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Dark Moon : une distribution GNU/Cygwin portable pour Windows. Évalué à 1.
Négatif ! Il faut faire un
sudopour pouvoir faire unaptitude update, par exemple.Pas sûr que ça s'oppose à ton affirmation, mais on peut le lancer dans conEmu, par exemple,
Là aussi, pas sûr que ça s'oppose à ton affirmation, mais on peut le lancer à partir d'une icône.
Zelbinium: Your Devices, Your Rules!
[^] # Re: Mais il n'y a vraiment pas de quoi...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -2.
Quand je me suis intéressé au développement d'interfaces natives, j'ai consulté la doc. et les tutos, pas de manière très approfondie, il est vrai, de toolkits comme Qt, wxWidgets, qui devait encore s'appeler wxWindows à l'époque, et d'autres dont je ne me souviens plus du nom. Or, je ne me souviens pas qu'il y soit jamais fait référence à MVC. Peut-être que je n'ai pas poussé ma lecture assez loin.
Lorsque je me suis intéressé au développement d'interfaces web, j'ai également consulté la doc. et les tutos de différents framework, et là, il y est rapidement fait référence à MVC. Et pourtant, je n'ai pas l'impression d'avoir pousser ma lecture plus loin qu'avec les docs et tutos ci-dessus, d'où ma méprise.
Zelbinium: Your Devices, Your Rules!
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 1. Dernière modification le 05 août 2018 à 14:00.
Merci !
C'est vraiment juste un truc que j'ai codé en mode quick and dirty, pour gérer les cas les plus évidents (
&,<,"…).Oui, c'est possible. D'un autre coté, vu le nombre d'outils qui existent pour faire du développement web dans d'autres langages, il y en a probablement pas mal qui ont une licence suffisamment permissive pour pouvoir s'en inspirer, voire carrément copier le code concerné, puisque pas mal de ces langages sont codés en interne en C ou en C++…
Zelbinium: Your Devices, Your Rules!
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 1.
Il y a moyen de voir les sources d'une de tes appli. avec interface native qui utilise MVC ?
Zelbinium: Your Devices, Your Rules!
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -5. Dernière modification le 05 août 2018 à 10:42.
Possible que je me sois gouré sur sur son degré d'utilisation mais j'aimerais quand même un lien sur une appli avec interface native qui utilise MVC et dont je peux voir les sources, et, vu ce que tu dis des documents dont tu m'as donné la référence, ça ne devrait pas être très difficile à produire…
Et je ne vois pas en quoi croire (même si, à priori, à tort) qu'une techno. n'est pas très utilisée, c'est la critiquer.
J'ai mon propre pattern d'archi, et je n'ai jamais dit que je n'étais pas capable de tester mon code, juste qu'écrire le code correspondant n'est, actuellement, pour moi, pas économiquement viable. Et, à l'instar de MVC, mon propre pattern d'archi est tout à fait adapté à l'écriture de tests, mais écrire le code de ces tests… (etc.).
Bref, rien ne prouve que tu n'aurais pas rencontré les mêmes problèmes avec mon appli. si je l'avais soumise à une batterie de tests que j'aurais codés. Je ne nie pas que ce soit possible, mais, de mon expérience, j'en estime la probabilité très faible, trop faible pour que j'investisse du temps (et donc de l'argent) pour pallier à cet hypothétique problème en codant des tests.
Je ne te convaincrais pas, tu ne me convaincras pas, donc je propose d'en rester là sur le sujet. Et cette proposition vaut aussi pour les autres qui seraient tenté d'intervenir sur ce même sujet.
M'ignorer ? Si l'alternative c'est d'avoir à répondre à des commentaires hors sujet et/ou contenant des arguments d'une part erronés et qui, d'autre part, ne font pas avancer le débat, oui, je préfère.
Zelbinium: Your Devices, Your Rules!
[^] # Re: Mais il n'y a vraiment pas de quoi...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 1.
https://github.com/epeios-q37/epeios/tree/master/apps/orgnzq/frontend/XDHTML, notamment les fichiers (.h/.cpp) prolog, login, main, column, field, fields, record et records.
Les journaux correspondants :
ou encore https://github.com/epeios-q37/epeios/tree/master/apps/mmuaq/frontend/XDHTML, notamment les fichiers (.h/.cpp) agent, agents, config, folders, mail, mails, prolog, login, main.
Les journaux correspondants :
mais tu ne vas probablement rien comprendre, parce que j'utilise un framework maison, et pas seulement pour la partie web. C'est pour ça que je n'en parle pas.
Les bindings Java, Node.js, PHP… permettent de faire abstraction de ce framework.
Zelbinium: Your Devices, Your Rules!
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -2.
Lorsque groumly écrivait :
je pensais qu'il faisait référence à des applications natives développées par Microsoft, Apple, Google, whoever…, qui s'appuient sur MVC et dont les sources sont consultables. C'est ça qui m'intéresse.
En outre, lorsqu'on clique sur le premier lien, il y a ça qui s'affiche :
Pour le reste :
Ces personnes me font de plus en plus penser à ça :
(source : https://xkcd.com/386/)
Zelbinium: Your Devices, Your Rules!
[^] # Re: Mais il n'y a vraiment pas de quoi...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -2. Dernière modification le 04 août 2018 à 17:36.
La seule raison que je puisse donner pour utiliser cette bibliothèque, c'est celle qui m'a motivée à la développer, c'est-à-dire pouvoir coder l'intégralité d'une application web en C++. Sauf, et je pense que l'ensemble des commentaires de ce journal l'ont clairement établit, que peu de personnes utiliseront cette bibliothèque pour cette raison. Au contraire même, le fait qu'il faille faire du C++ pour l'utiliser serait même plutôt, pour beaucoup de personnes, une raison de ne pas l'utiliser. Je ne critique pas, je constate. Du coup, je me suis bien gardé d'avancer cette raison.
Avant de me lancer dans son développement, j'ai regardé ce qui existait, et j'ai constaté que beaucoup d'outils s'appuyaient sur MVC. J'ai regardé ce dont il s'agissait, et je n'en pas vu l'intérêt, sachant que ça fait des années que je développe des interfaces natives sans avoir à m'appuyer sur MVC. Là aussi, apparemment, je fais figure d'exception, semble-t-il, vu que, selon certains commentaires, MVC semble être aussi la norme en matière d'interfaces natives.
Bref, n'ayant jamais utilisé l'un de ces outils basé sur MVC, je serais bien en peine d'avancer ne fût-ce qu'une raison qui pourrait pousser quelqu'un à délaisser son outil au profit de ma bibliothèque, et ce malgré tous les bindings que je pourrais réaliser pour faciliter l'accès à cette bibliothèque. C'est malheureux, mais c'est ainsi. En outre, ces personnes seront d'autant plus réticent qu'il leur a certainement fallu pas mal de temps pour maîtriser l'outil qu'ils utilisent. Il faudra donc de sacrées bonnes raisons pour les pousser à faire une croix sur cet investissement au profit de ma bibliothèque…
Clairement, Le gros problème de ce projet, c'est moi. Ça lui serait nettement plus bénéfique si je pouvais me cantonner à l'aspect technique, et laisser quelqu'un de plus doué que moi en communication en faire la promotion. Sauf que, pour l'instant, je suis seul sur ce projet, et donc, je fais avec. Donc, je communique tant bien que mal, apparemment plutôt mal que bien, sachant qu'il est toujours préférable de mal communiquer que de ne pas communiquer du tout !
Je ne sais plus si c'est dans ce journal ou l'autre que j'en parle, mais j'ai le projet d'animer des ateliers autour de cette bibliothèque. Le fait qu'elle soit disponible en plusieurs langages et simple à installer, combiné au fait qu'elle permet de manipuler, sans artifices particuliers, les concepts de base des technos web, à savoir HTML, CSS et DOM, je pense que cette bibliothèque est un bon outil d'initiation à ces concepts. J'ignore si ces ateliers seront, par ailleurs, profitables à ma bibliothèque, mais, là encore, mieux vaut faire ces ateliers que de ne rien faire du tout…
Zelbinium: Your Devices, Your Rules!
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -3. Dernière modification le 04 août 2018 à 12:32.
Ce n'est pas parce que les plus gros l’utilisent que c'est la norme…
Plus précisément, je ne me rappelle pas avoir jamais vu quoique ce soit de relatif au MVC dans les codes d'application natifs que j'ai pu voir, ni dans les tutoriaux des différents toolkits (s'ils l'abordent, ça doit vraiment être dans les chapitres les plus avancés)…
Mais ça m'intéresse de voir comment c'est mis en œuvre. Tu parles de quoi exactement quand tu me suggères de regarder ce que font Microsoft, Apple et google ?
Zelbinium: Your Devices, Your Rules!
[^] # Re: Mais il n'y a vraiment pas de quoi...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 0.
Ce chapitre ne te concerne pas personnellement (d'où le vouvoiement, alors que j'ai utilisé le tutoiement pour m'adresser à toi juqu'à présent). C'est juste un résumé de l'objectif du journal, à l'intention de tout ceux qui liraient ce commentaire et pour qui cela ne serait pas clair.
Quand je dis que je suis un mauvais communicant…
Zelbinium: Your Devices, Your Rules!
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 1.
Oui mais, aussi bancal que ce soit, c'est toujours plus facile que d'avoir à partir de zéro. En outre, aussi expérimenté que soit le développeur, je doute qu'il y en ai beaucoup qui sachent interfacer du PHP avec du C++, mais je me trompe peut-être…
Ceci dit, pour le coup, j'ai peut-être une connaissance faisant du PHP qui pourra m'aider…
Soit.
En fait, si je comprend bien en faisant
[String] tata = "tutu;", lenewest fait automatiquement, c'est cela ?Franchement, je ne vois pas le problème, mais bon…
OK, je n'aurais donc aucun scrupule à l'utiliser.
OK.
OK ! Pas taper ! Je vais mettre un commentaire !
Super !
Sauf qu'en C++, le compilateur n'impose jamais une correspondance entre le nom d'un fichier et son contenu, donc on est plus facilement tenté de d'accumuler les classes dans un seul et même fichier (je ne dis pas que c'est une bonne chose !)
Je connaissais les Integer, je les utilise dans certains contextes, mais là il me semblait plus pertinent d'utiliser un
int, pensant, sans doute à tord, que c'est plus léger qu'unInteger.Et je vais l'adopter.
L'une comme l'autre forme me convienne parfaitement, mais si ça peut faciliter la lecture à certains…
Par contre, le ShowBidule/HideBidule, faut voir, car ce sont des identifiant d'éléments de style, et ça risque de les alourdir.
S'il n'y a effectivement rien à installer de plus, je vais probablement l'utiliser.
OK. Je vais voir ça.
Et tu as lancé le bordel dans un environnement sans interface graphique ? Je subodore que c'est ce qui est arrivé à barmic, mais je n'en ai pas la confirmation…
En tout cas merci pour tes retours…
Zelbinium: Your Devices, Your Rules!
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -2.
Voir https://linuxfr.org/users/epeios/journaux/du-developpement-full-stack-en-java#comment-1745710
Zelbinium: Your Devices, Your Rules!
[^] # Re: Il vaudrait mieux te mettre en contact avec quelqu'un qui connait Java
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 1.
Franchement, vu mon niveau en Java, ça ne va sans doute pas le faire. En outre, j'ai déjà bien assez à faire avec mes propres projets open source. Et j'ai déjà pas mal de grain à moudre avec les commentaires de ce journal.
Merci pour les pointeurs. N'étant pas omniscient, ça ne fait pas de doute que j'y apprendrais des choses…
Zelbinium: Your Devices, Your Rules!