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…
Pour nous émanciper des géants du numérique : Zelbinium !
(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.
Pour nous émanciper des géants du numérique : Zelbinium !
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.
Pour nous émanciper des géants du numérique : Zelbinium !
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…
Pour nous émanciper des géants du numérique : Zelbinium !
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.
Pour nous émanciper des géants du numérique : Zelbinium !
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…
Pour nous émanciper des géants du numérique : Zelbinium !
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
Pour nous émanciper des géants du numérique : Zelbinium !
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…
Pour nous émanciper des géants du numérique : Zelbinium !
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).
Pour nous émanciper des géants du numérique : Zelbinium !
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.
Pour nous émanciper des géants du numérique : Zelbinium !
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.
Pour nous émanciper des géants du numérique : Zelbinium !
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++…
Pour nous émanciper des géants du numérique : Zelbinium !
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.
Pour nous émanciper des géants du numérique : Zelbinium !
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.
Pour nous émanciper des géants du numérique : Zelbinium !
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…
Pour nous émanciper des géants du numérique : Zelbinium !
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 ?
Pour nous émanciper des géants du numérique : Zelbinium !
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…
Pour nous émanciper des géants du numérique : Zelbinium !
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…
En tout cas merci pour tes retours…
Pour nous émanciper des géants du numérique : Zelbinium !
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…
Pour nous émanciper des géants du numérique : Zelbinium !
Je n'ai jamais prétendu qu'il n'est pas possible d'utiliser MVC pour une interface native, mais il me semble que MVC, c'est plutôt presque la règle pour les interfaces web, alors que c'est plutôt l'exception pour les interfaces natives…
Pour nous émanciper des géants du numérique : Zelbinium !
Je vais prendre le temps de te dire ce que je pense de ton approche :) Ça va peut être être rude, mais comprends bien que si je prends du temps pour écrire un commentaire c'est bien que je veux être constructif. De plus je distingue totalement ton travaille de la personne que tu es (c'est important). Mais il y a pas mal de choses à dire je trouve.
Super ! Je n'attend que ça, des commentaires constructifs !
Ton approche
Background
Tu connais le C++, tu vis le C++ en autarcie, tu nous explique à longueur de journée que les pratiques classiques comme les tests ne sont pas pour toi.
Bon, on ne va pas reprendre cette discussion ici, mais je n'ai jamais dit que les tests ne sont pas pour moi. Tout ce que j'ai dit, c'est que, comme tout un chacun, je me sentirais bien mieux si je pouvais prendre le temps de soumettre mon code à des test, mais que, ce n'est pas, pour moi, en l'état actuel des choses, économiquement viable de passer du temps à écrire des tests. Peut-être qu'un jour, le temps que je gagne à ne pas écrire de tests sera significativement inférieur au temps que j'aurais gagné en soumettant mon code à ces tests. Ce jour-là, j'écrirais des tests. Quoiqu'il en soit, j'encourage tout un chacun à écrire des tests auxquels soumettre leur code.
En informatique comme ailleurs affirmer que l'on est plus malin/différents/le cas à part, c'est se tromper.Tu as des centaines de milliers de personnes dans le monde qui après une cinquantaine d'années à tenter de construire une certaine qualité logicielle. Arriver et dédaigner leur travail, par un « bof c'est pour les autres », c'est forcément se tromper.
Où ai-je affirmé de telles choses ? Le fait est que, moi, je n'ai absolument aucun problème avec les personnes qui ne codent pas uniquement en C++. Par contre, il semble que, parmi ces personnes, il y en a à qui cela pose un gros problème que je code uniquement en C++…
On exerce une science dure, pour affirmer des choses il faut avoir des arguments autre que « je fais de la factorisation poussée » (personne d'autre ne factorise ?). De tout ce que tu nous as décrit ça "fonctionne" parce que tu es le seul à coder et que tu accepte de voir très tard les bugs (tu reconstruit les autres logiciels et tu teste s'il plantent).
Si tu relis la partie que tu cites, tu constateras que j'ai explicitement parlé d'hypothèse, et que donc je reconnaissais implicitement que ce que j'avançais n'était peut-être pas la bonne explication. Quand aux bugs, je les découvre peut-être plus tard que si j'utilisais une batterie de tests, mais toutefois suffisamment tôt pour qu'ils ne gênent pas mes clients. Et c'est le plus important, non ? (Par contre, ton histoire de reconstruire les autres logiciels et de tester s'ils plantent, là, je n'ai pas trop compris…)
Tu pars donc très très très mal : tu nous propose d'utiliser un code pas tester (yay !), mais pour quoi donc ?
Je n'écris pas explicitement de code de test, mais je lance toutefois quand plusieurs fois même mon application au cours de son développement pour voir si elle se comporte correctement, et, en outre, sur plusieurs plate-formes (notamment GNU/Linux, macOS et Windows)…
Objectif
Tu ne sais faire que du C++, quelqu'un te demande de faire du web, tu fais du web en C++. Très bien. Mais la populace fais déjà du web avec un tas d'autres choses. Il va falloir nous donner une raison d'abandonner nos stack libres bien plus fiables que la tienne (dont le copyright est partagé, supporté par une communauté, testée, testée massivement,…).
Pourquoi devrais-je donner une raison ? Je donne à tout un chacun le moyen de tester ma bibliothèque pour qu'il puisse se forger sa propre opinion à son propos. Après, libre à lui d'en rester à sa stack bien-aimée ad vitam æternam, peu me chaut…
En plus du web, il existe un énorme paquet de techno qui apparaît. Ça signifie qu'il y a déjà énormément d'idées qui ont étaient essayée. D'autant que ça fais des années que ça dure !
Euh… Soit ! Et ?
Tu ne nous a pas donné d'autres arguments sur le pourquoi utiliser ta pile autre que c'est du C++ et c'est simple… oui mais.
J'ai surtout donné un moyen, que j'ai essayé de rendre le plus simple possible, pour tout un chacun de l'essayer et ainsi de pouvoir se forger sa propre opinion… (oui, je sais, je me répète).
Alternatives
Tu n'a aucune idée de si c'est simple, tu en ai l'utilisateur-codeur et tu n'es même pas allé voir ce qui se fait ailleurs. On ne souffre pas la comparaison quand on en fait pas mais on va forcément la faire pour toi. Qu'est-ce que ça donne comparé à du CGI ? Qu'est-ce que ça donne face à Wt ? Pourquoi les gens choisiraient le code d'un développeur dans son garage (pas testé) par rapport à tout ce qui peut exister ailleurs ?
Si, je suis allé voir ce qui se faisait ailleurs, mais cela ne me convenait pas. Et comme c'est déjà les principes de base qui ne me convenaient pas, je n'ai pas essayé, donc je suis particulièrement mal placé pour émettre une comparaison objective de ma bibliothèque avec l'existant. Et encore une fois, je n'essaie de convaincre personne d'utiliser ma bibliothèque…
J'ai parlé de techno C++, mais alors j'ai pas de doute qu'en PHP, Java et JS c'est pire encore.
Pas compris ce tu essayes d'exprimer, là…
Finalement
En vrai je ne sais pas pourquoi tu nous présente des plus ou moins portages dans d'autres langages, tu ne les utilise pas et tu n'explique pas en quoi les développeurs de ce langage gagneraient à utiliser ton code.
Déjà, ce ne sont pas des portages, mais des bidings, c'est à dire que le cœur de la bibliothèque est le même, quelque soit le langage utilisé. Et, encore une fois, pourquoi j'essayerais de convaincre qui que ce soit par quelqu'argument que ce soit des qualités de ma bibliothèque s'il existe un moyen, que j'ai essayé de rendre le plus simple possible, de l'essayer (bis, ou plutôt, ter repetita) ? S'il n'est alors pas capable de se forger sa propre opinion, je ne peux rien pour lui…
Pire encore, tu nous parle d'une bibliothèque C++, je sais pas ce qu'elle fais. Si je vais voir http://atlastk.org/ (pas de https ?), tu nous dis que c'est du C++ donc c'est rapide. Si tu ne le corrobore pas avec des benchmarks c'est du vent. Tu nous explique pas en quoi ta bibliothèque est performante. Quelle archi est-ce que tu utilise ? Comment-est-ce que tu t'assure que tes bindings restent performant ? Tu connais netty ? C'est ce qui permet à Java d'être performant sur le réseau, il faut vraiment avoir des arguments pour pouvoir dire qu'on est plus performant que ça.
(Si, il y a du https, mais je ne force personne à l'utiliser.)
Sérieux, tu veux vraiment que je développe, ou fasse développer, ma bibliothèque dans tous les langages disponibles juste pour pouvoir faire des benchmarks ?
La bibliothèque étant à l'état de prototype, il est inutile de rentrer dans les détails techniques, vu que ces derniers ont de grandes choses de considérablement évoluer…
Concernant le C++, je ne pense que beaucoup considère que ce soit un mauvais choix si on cherche à obtenir les meilleures performances possibles…
La mise en œuvre
D'un point de vu utilisateur
Ton code nous montre du html dans des String. Donc on peut dire au revoir à la validation du html. On peut faire autrement ? Très bien montre nous et c'est là dessus qu'on évaluera si c'est facile ou pas.
Comme j'ai dit dés l'introduction, je ne suis pas familier avec Java. Certaines fonctions prennent une String devant contenir du HTML, et j'ai donc créer le contenu de ces String à la main pour éviter d'avoir à installer un outil tiers (il y a peut-être un outil fournit en standard ; n'ayant pas cherché, je l'ignore), et cela fonctionne très bien. Maintenant, s'il y en a qui sont incapables d'écrire du code HTML valide à la main, libre à eu de passer par l'outil de leur choix…
Tu nous montre aussi des manipulation de DOM, c'est affreux à utiliser… et c'est extrêmement lent ! C'est bien pour ça que toutes les techno utilisent un DOM virtuel… Aie…
Les goûts et les couleurs…
Perso., je préfère manipuler le DOM que de passer systématiquement par un moteur de template et de me farcir du MVC. Mais ça, c'est mon choix personnel, que je n'impose à personne.
Et je rappelle que ce qui est présenté ici, comme indiqué dans l'introduction de ce journal, c'est un prototype, donc quelque chose de largement améliorable. Il est tout à fait possible qu'à partir d'une des prochaines version de cette bibliothèque s'appuie sur un DOM virtuel.
D'un point de vu conception
Si je regarde Atlas.jar c'est ta classe principale, hein ? Tu as des chemins codés en dur dans ton code… C'est pas une question de java, il n'y a pas de langage dans le quel c'est une bonne pratique…
Les chemins en dur ne sont utilisés que dans mon environnement de développement. Si ma bibliothèque est installé en suivant la procédure indiquée dans ce journal, ces chemins ne sont pas utilisés.
Tu lance des Threads non managés. Tu ne les nettoie pas. Ton code explose, c'est une garantie.
D'après toi qu'est-ce qui est affiché par ce code ? java
public void foo() {
System.out.println("start");
new Thread(() -> {
try {
Thread.sleep(1_000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("Hello");
}).start();
System.out.println("end");
}
Même si tu ne lançais un thread qu'à chaque connexion, ça exploserais à quelques dizaines de milliers de connexions. Le problème ce n'est pas que tu refuserais des connexions, mais bien que le serveur tombe à ce moment là…
Encore une fois, la version présentée ici n'est qu'un prototype. Si une meilleure gestion des threads est requise, elle sera implémentée..
Et je n'ai aucune idée de ce qui est affiché par ton code (et je m'en contrefiche un peu…).
Tentons de voir s'il n'y a pas un truc que je rate dans ton code. Si je tente de lancer ton premier exemple :
michel@MBA:/tmp/tmp.msaUgm9EXO % java -cp .:Atlas.jar Hello
java.lang.UnsupportedOperationException: The BROWSE action is not supported on the current platform!
at java.awt.Desktop.checkActionSupport(Desktop.java:225)
at java.awt.Desktop.browse(Desktop.java:381)
at info.q37.xdhq.dom.DOM_DEMO.<init>(DOM_DEMO.java:154)
at info.q37.xdhq.DOM.<init>(DOM.java:48)
at info.q37.atlas.DOM.<init>(DOM.java:24)
at info.q37.atlas.Atlas.<init>(Atlas.java:28)
at Hello.<init>(Hello.java:3)
at Hello.main(Hello.java:48)
Exception in thread "Thread-0" java.lang.NullPointerException
at info.q37.xdhq.DOM.getAction(DOM.java:62)
at info.q37.atlas.Atlas.run(Atlas.java:38)
at java.lang.Thread.run(Thread.java:748)
Mais ça continue à s'exécuter, mais il n'écoute pas de port. Awt c'est une bibliothèque graphique, je ne sais pas ce que ça vient faire là, je pensais lancer un serveur web… Le code lance, une classe démo de ta bibliothèque ?…
En fonctionnement normal, un serveur est effectivement lancé, mais ce fonctionnement, tel que la bibliothèque est codée, nécessite l'installation de code natif en local. Pour éviter cela, et, du coup, simplifier la procédure d'installation, le fonctionnement pas défaut ne lance pas de serveur.
Je tente tellement silencieusement d'accéder à cette adresse qu'elle est normalement affichée en clair dans la console à partir de laquelle l'application est lancée… Mais elle ne s'est probablement pas affichée chez toi à cause du message d'erreur.
Cette adresse est en fait celle à laquelle on doit se connecter avec un navigateur web pour accéder à l'application qui vient d'être lancée. Normalement, un navigateur pointant sur cette adresse est automatiquement lancé, mais ça échoue chez toi, peut-être parce que tu as lancé l'application dans un environnement sans interface graphique (quoique ce cas est normalement prévu).
Quand à l'erreur, je pensais avoir traité le cas de figure où le lancement d'un navigateur n'est pas possible, mais apparemment pas. Normalement, dans ce cas de figure, un message est affiché dans la console invitant à ouvrir un navigateur à l'adresse que tu as relevée.
Je passe sur une partie de ton message, car, malgré le message d'erreur, l'application fonctionne probablement. Il suffit de se connecter avec un navigateur web à l'adresse que tu as relevée (attention : elle change à chaque lancement de l'application). En tout cas merci pour le pointeur pour corriger le problème concernant le lancement d'un navigateur.
Pour ma première partie :
garde l'humilité d'aller voir ce qui se fait ailleurs
Ne t'en fait pas, je regarde volontiers ce qui se fait ailleurs, non par humilité, mais par simple curiosité…
si tu veux qu'on passe du temps à apprendre ton truc explique nous ce qu'il a de plus et être en C++ ça n'est pas une bonne raison (surtout si c'est pour tout coder en java)
Entièrement d'accord, le fait d'être codé en C++ n'est absolument pas un critère en soi pour utiliser une bibliothèque (et je n'ai jamais prétendu le contraire), fût-ce à travers un bindingJava ; en fait, ça serait même une raison de ne pas utiliser cette bibliothèque pour tout autre langage que le C++, compte tenu de l'inaptitude du gestionnaire de paquets de la plupart des langages (s'il existe !) à gérer correctement le déploiement de code natif. Mais, comme dit, avec la procédure d'installation telle que détaillée dans ce journal, il n'y a pas ce problème, puisque il n'y a pas de code natif qui est installé localement.
Le seul but de ce journal, c'est de présenter un projet et de fournir un moyen simple de l'essayer. Si ce projet ne vous intéresse pas, il vous suffit de passer votre chemin (si possible, sans essayer de me convaincre de ne pas utiliser C++ pour faire du web ; ce n'est pas le sujet, et ça n'apporte absolument rien au débat). S'il vous intéresse, libre à vous de l'essayer, et de me faire remonter vos observations, que je lirais attentivement, via les commentaires.
Et, encore une fois, tout n'est pas codé en Java. Ce qui est codé en Java, c'est uniquement un wrapper (en fait, c'est un peu plus qu'un simple wrapper).
J'ai passé du temps a regarder ce que tu as fais et à rédiger mon commentaire (il est mieux construit au début qu'à la fin, mais c'est la fatigue), je sui réellement allé cherché ton code et j'ai tenté de le lancer. Comprends que si ton truc ne marche pas en y aillant passé environ 1h30 à 2h, c'est qu'il y a un vrai problème. Je connais le java et je peux aller voir ce qu'il s'y passe. J'aurais pu lancer n'importe quel hello world vu, angular, react, elm, python ou brainfuck en 10 minutes. En terme de qualité c'est très loin de ce que l'on peut attendre d'un truc qu'on voudrait réutiliser (dans un cadre professionnel ou pas).
Désolé que tu y ai passé tout ce temps, alors que ça fonctionnait probablement dés le début… Et encore une fois, c'est indiqué dans le journal, ce qui est présenté ici, c'est un prototype, donc quelque chose qui est uniquement mis à disposition pour quiconque voudrait l'essayer, et absolument pas pour être utilisé dans un cadre professionnel…
En tout cas, merci d'avoir pris le temps d'essayer ce logiciel, et de rédiger un commentaire qui soit plus constructif que la plupart de ceux que j'ai pu lire jusqu'à présent… Il me confirme que je suis vraiment pas doué en terme de communication…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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 :
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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).
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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++…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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 ?
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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/)
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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 ?
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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.
Je n'ai jamais prétendu qu'il n'est pas possible d'utiliser MVC pour une interface native, mais il me semble que MVC, c'est plutôt presque la règle pour les interfaces web, alors que c'est plutôt l'exception pour les interfaces natives…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # 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.
Sommaire
Salut !
Super ! Je n'attend que ça, des commentaires constructifs !
Bon, on ne va pas reprendre cette discussion ici, mais je n'ai jamais dit que les tests ne sont pas pour moi. Tout ce que j'ai dit, c'est que, comme tout un chacun, je me sentirais bien mieux si je pouvais prendre le temps de soumettre mon code à des test, mais que, ce n'est pas, pour moi, en l'état actuel des choses, économiquement viable de passer du temps à écrire des tests. Peut-être qu'un jour, le temps que je gagne à ne pas écrire de tests sera significativement inférieur au temps que j'aurais gagné en soumettant mon code à ces tests. Ce jour-là, j'écrirais des tests. Quoiqu'il en soit, j'encourage tout un chacun à écrire des tests auxquels soumettre leur code.
Où ai-je affirmé de telles choses ? Le fait est que, moi, je n'ai absolument aucun problème avec les personnes qui ne codent pas uniquement en C++. Par contre, il semble que, parmi ces personnes, il y en a à qui cela pose un gros problème que je code uniquement en C++…
Si tu relis la partie que tu cites, tu constateras que j'ai explicitement parlé d'hypothèse, et que donc je reconnaissais implicitement que ce que j'avançais n'était peut-être pas la bonne explication. Quand aux bugs, je les découvre peut-être plus tard que si j'utilisais une batterie de tests, mais toutefois suffisamment tôt pour qu'ils ne gênent pas mes clients. Et c'est le plus important, non ? (Par contre, ton histoire de reconstruire les autres logiciels et de tester s'ils plantent, là, je n'ai pas trop compris…)
Je n'écris pas explicitement de code de test, mais je lance toutefois quand plusieurs fois même mon application au cours de son développement pour voir si elle se comporte correctement, et, en outre, sur plusieurs plate-formes (notamment GNU/Linux, macOS et Windows)…
Pourquoi devrais-je donner une raison ? Je donne à tout un chacun le moyen de tester ma bibliothèque pour qu'il puisse se forger sa propre opinion à son propos. Après, libre à lui d'en rester à sa stack bien-aimée ad vitam æternam, peu me chaut…
Euh… Soit ! Et ?
J'ai surtout donné un moyen, que j'ai essayé de rendre le plus simple possible, pour tout un chacun de l'essayer et ainsi de pouvoir se forger sa propre opinion… (oui, je sais, je me répète).
Si, je suis allé voir ce qui se faisait ailleurs, mais cela ne me convenait pas. Et comme c'est déjà les principes de base qui ne me convenaient pas, je n'ai pas essayé, donc je suis particulièrement mal placé pour émettre une comparaison objective de ma bibliothèque avec l'existant. Et encore une fois, je n'essaie de convaincre personne d'utiliser ma bibliothèque…
Pas compris ce tu essayes d'exprimer, là…
Déjà, ce ne sont pas des portages, mais des bidings, c'est à dire que le cœur de la bibliothèque est le même, quelque soit le langage utilisé. Et, encore une fois, pourquoi j'essayerais de convaincre qui que ce soit par quelqu'argument que ce soit des qualités de ma bibliothèque s'il existe un moyen, que j'ai essayé de rendre le plus simple possible, de l'essayer (bis, ou plutôt, ter repetita) ? S'il n'est alors pas capable de se forger sa propre opinion, je ne peux rien pour lui…
(Si, il y a du https, mais je ne force personne à l'utiliser.)
Sérieux, tu veux vraiment que je développe, ou fasse développer, ma bibliothèque dans tous les langages disponibles juste pour pouvoir faire des benchmarks ?
La bibliothèque étant à l'état de prototype, il est inutile de rentrer dans les détails techniques, vu que ces derniers ont de grandes choses de considérablement évoluer…
Concernant le C++, je ne pense que beaucoup considère que ce soit un mauvais choix si on cherche à obtenir les meilleures performances possibles…
Comme j'ai dit dés l'introduction, je ne suis pas familier avec Java. Certaines fonctions prennent une
Stringdevant contenir du HTML, et j'ai donc créer le contenu de cesStringà la main pour éviter d'avoir à installer un outil tiers (il y a peut-être un outil fournit en standard ; n'ayant pas cherché, je l'ignore), et cela fonctionne très bien. Maintenant, s'il y en a qui sont incapables d'écrire du code HTML valide à la main, libre à eu de passer par l'outil de leur choix…Les goûts et les couleurs…
Perso., je préfère manipuler le DOM que de passer systématiquement par un moteur de template et de me farcir du MVC. Mais ça, c'est mon choix personnel, que je n'impose à personne.
Et je rappelle que ce qui est présenté ici, comme indiqué dans l'introduction de ce journal, c'est un prototype, donc quelque chose de largement améliorable. Il est tout à fait possible qu'à partir d'une des prochaines version de cette bibliothèque s'appuie sur un DOM virtuel.
Les chemins en dur ne sont utilisés que dans mon environnement de développement. Si ma bibliothèque est installé en suivant la procédure indiquée dans ce journal, ces chemins ne sont pas utilisés.
Encore une fois, la version présentée ici n'est qu'un prototype. Si une meilleure gestion des threads est requise, elle sera implémentée..
Et je n'ai aucune idée de ce qui est affiché par ton code (et je m'en contrefiche un peu…).
En fonctionnement normal, un serveur est effectivement lancé, mais ce fonctionnement, tel que la bibliothèque est codée, nécessite l'installation de code natif en local. Pour éviter cela, et, du coup, simplifier la procédure d'installation, le fonctionnement pas défaut ne lance pas de serveur.
Je tente tellement silencieusement d'accéder à cette adresse qu'elle est normalement affichée en clair dans la console à partir de laquelle l'application est lancée… Mais elle ne s'est probablement pas affichée chez toi à cause du message d'erreur.
Cette adresse est en fait celle à laquelle on doit se connecter avec un navigateur web pour accéder à l'application qui vient d'être lancée. Normalement, un navigateur pointant sur cette adresse est automatiquement lancé, mais ça échoue chez toi, peut-être parce que tu as lancé l'application dans un environnement sans interface graphique (quoique ce cas est normalement prévu).
Quand à l'erreur, je pensais avoir traité le cas de figure où le lancement d'un navigateur n'est pas possible, mais apparemment pas. Normalement, dans ce cas de figure, un message est affiché dans la console invitant à ouvrir un navigateur à l'adresse que tu as relevée.
Je passe sur une partie de ton message, car, malgré le message d'erreur, l'application fonctionne probablement. Il suffit de se connecter avec un navigateur web à l'adresse que tu as relevée (attention : elle change à chaque lancement de l'application). En tout cas merci pour le pointeur pour corriger le problème concernant le lancement d'un navigateur.
Ne t'en fait pas, je regarde volontiers ce qui se fait ailleurs, non par humilité, mais par simple curiosité…
Entièrement d'accord, le fait d'être codé en C++ n'est absolument pas un critère en soi pour utiliser une bibliothèque (et je n'ai jamais prétendu le contraire), fût-ce à travers un binding Java ; en fait, ça serait même une raison de ne pas utiliser cette bibliothèque pour tout autre langage que le C++, compte tenu de l'inaptitude du gestionnaire de paquets de la plupart des langages (s'il existe !) à gérer correctement le déploiement de code natif. Mais, comme dit, avec la procédure d'installation telle que détaillée dans ce journal, il n'y a pas ce problème, puisque il n'y a pas de code natif qui est installé localement.
Le seul but de ce journal, c'est de présenter un projet et de fournir un moyen simple de l'essayer. Si ce projet ne vous intéresse pas, il vous suffit de passer votre chemin (si possible, sans essayer de me convaincre de ne pas utiliser C++ pour faire du web ; ce n'est pas le sujet, et ça n'apporte absolument rien au débat). S'il vous intéresse, libre à vous de l'essayer, et de me faire remonter vos observations, que je lirais attentivement, via les commentaires.
Et, encore une fois, tout n'est pas codé en Java. Ce qui est codé en Java, c'est uniquement un wrapper (en fait, c'est un peu plus qu'un simple wrapper).
Désolé que tu y ai passé tout ce temps, alors que ça fonctionnait probablement dés le début… Et encore une fois, c'est indiqué dans le journal, ce qui est présenté ici, c'est un prototype, donc quelque chose qui est uniquement mis à disposition pour quiconque voudrait l'essayer, et absolument pas pour être utilisé dans un cadre professionnel…
En tout cas, merci d'avoir pris le temps d'essayer ce logiciel, et de rédiger un commentaire qui soit plus constructif que la plupart de ceux que j'ai pu lire jusqu'à présent… Il me confirme que je suis vraiment pas doué en terme de communication…
Pour nous émanciper des géants du numérique : Zelbinium !