Journal Prototypage d'applications web

-9
5
sept.
2018

Logos Java, Node.js et PHP

La version 0.2.0 du toolkit Atlas implémente une nouvelle architecture facilitant le prototypage d'applications web. Pour ce faire, cette architecture présente deux particularités :

  • la possibilité de développer une interface web avec à peu prés n'importe quel langage,
  • le peu de choses à installer pour mettre en œuvre cette architecture.

Les versions Java, Node.js et PHP démontrent qu'il suffit qu'un langage offre la possibilité de gérer des connexions réseau pour qu'il puisse tirer profit de cette architecture.

Une autre particularité de cette architecture réside dans le fait qu'il suffit qu'une application basée sur ce toolkit soit lancée sur un ordinateur ayant accès à internet (il n'est pas nécessaire qu'il soit accessible à partir d'internet) pour qu'elle soit accessible de n'importe où sur internet. Le développeur n'a pas à déployer quoique ce soit sur un serveur distant pour ce faire.

Cette architecture est constituée de deux parties.

La première est une bibliothèque qui est, pour simplifier son installation et sa mise en œuvre, codée dans le langage choisi par le développeur pour son prototype d'application web ; c'est le seul élément à installer sur l'ordinateur de développement.

Le seconde, à laquelle la première se connecte, est constituée d'un ensemble de logiciels qui tournent sur un serveur distant (accessible, lui, d'internet). Pour éviter au développeur d'avoir à s'en occuper, un tel serveur, auquel le toolkit se connecte automatiquement, est gracieusement mis à disposition.

Plus d'information sur http://atlastk.org/.

  • # Montre ton code

    Posté par . Évalué à 6. Dernière modification le 05/09/18 à 21:43.

    Il manque clairement des trucs ; déjà, si ce truc fait ce qu'il dit, ce journal devrait être une dépêche.

    Mais surtout, ça manque de code !

    Je suggère de l'insérer à la suite des paragraphes qui font envie:

    Une autre particularité de cette architecture réside dans le fait qu'il suffit qu'une application basée sur ce toolkit soit lancée sur un ordinateur ayant accès à internet (il n'est pas nécessaire qu'il soit accessible à partir d'internet) pour qu'elle soit accessible de n'importe où sur internet. Le développeur n'a pas à déployer quoique ce soit sur un serveur distant pour ce faire.

    Exemple:

    yo() {
    internet=false;
    spawnService();
    }

    Cette architecture est constituée de deux parties.

    La première est une bibliothèque qui est, pour simplifier son installation et sa mise en œuvre, codée dans le langage choisi par le développeur pour son prototype d'application web ; c'est le seul élément à installer sur l'ordinateur de développement.

    Exemple:

    yu() {
    spawnView()
    }

    Le seconde, à laquelle la première se connecte, est constituée d'un ensemble de logiciels qui tournent sur un serveur distant (accessible, lui, d'internet). Pour éviter au développeur d'avoir à s'en occuper, un tel serveur, auquel le toolkit se connecte automatiquement, est gracieusement mis à disposition.

    Exemple:

    yu() {
    spawnServer()
    }

    Sans ça, un autre truc qui nuirait pas, vu la profusion de frameworks pour faire du web ces temps-ci, c'est une partie "problème / solution" qui expliquerait un rien pourquoi on utiliserait celui-ci plutôt qu'un autre.

    • [^] # Re: Montre ton code

      Posté par (page perso) . Évalué à 4. Dernière modification le 31/10/18 à 22:22.

      J'allais suggérer d'écrire une dépêche en espace collectif. Parce que, Claude Simon, tes phrases ont tendance à l'alambiquation (mot qui vient certainement autant du contenu de l'alambic qui donne mal à la tête au réveil que de sa forme qui invite à la rêverie).

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Montre ton code

        Posté par (page perso) . É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).

        Toolkit Atlas : probablement le moyen le plus simple et le plus rapide pour ajouter une interface graphique à vos programmes Java, Node.js, Python… (voir page perso) !

        • [^] # Re: Montre ton code

          Posté par (page perso) . Évalué à 2.

          Les questions et les réponses détaillées que tu apportes sont une belle base de départ.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Montre ton code

      Posté par (page perso) . Évalué à 10.

      Plus que du code, je montrerais plutôt un schéma. Parce que depuis le temps que je vois passer tes journaux, je n'ai toujours pas compris qu'est-ce qui s'exécute où avec ton framework.

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: Montre ton code

        Posté par (page perso) . É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…

        Toolkit Atlas : probablement le moyen le plus simple et le plus rapide pour ajouter une interface graphique à vos programmes Java, Node.js, Python… (voir page perso) !

        • [^] # Re: Montre ton code

          Posté par (page perso) . Évalué à 7.

          Le schéma est indispensable à cause de ça :

          Le seconde, à laquelle la première se connecte, est constituée d'un ensemble de logiciels qui tournent sur un serveur distant (accessible, lui, d'internet). Pour éviter au développeur d'avoir à s'en occuper, un tel serveur, auquel le toolkit se connecte automatiquement, est gracieusement mis à disposition.

          Il est des applications pour lesquelles il est impensable que quoi que ce soit tourne sur un serveur tiers inconnu. Si je n'ai pas un schéma clair qui m'explique qu'est-ce qui tourne où, et quelles sont les alternatives disponibles, ton framework est disqualifié d'office.

          La connaissance libre : https://zestedesavoir.com

          • [^] # Re: Montre ton code

            Posté par (page perso) . Évalué à 4. Dernière modification le 07/09/18 à 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 :

            Machine util.    Serveur distant                         Machine développeur
            ------------     -----------------------------------     ----------------------
            | nav. web | --> | apache --> xdhwebq-cli --> xdhq | <-- | xdhq-.../atlas-... |
            ------------     -----------------------------------     ----------------------
            
            Signification de la flèche :
            client --> serveur

            Toolkit Atlas : probablement le moyen le plus simple et le plus rapide pour ajouter une interface graphique à vos programmes Java, Node.js, Python… (voir page perso) !

            • [^] # Re: Montre ton code

              Posté par . Évalué à 5.

              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.

              Un bon prototype c'est - entre autres - un prototype qu'on peut reprendre en grande partie pour construire l'application cible.

              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" ?

              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 ?

              • [^] # Re: Montre ton code

                Posté par (page perso) . Évalué à 1. Dernière modification le 07/09/18 à 15:47.

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

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

                Toolkit Atlas : probablement le moyen le plus simple et le plus rapide pour ajouter une interface graphique à vos programmes Java, Node.js, Python… (voir page perso) !

                • [^] # Re: Montre ton code

                  Posté par . Évalué à 8. Dernière modification le 07/09/18 à 19:31.

                  Ah ben ca va bien se passer a la fin de la pres'.
                  - Bon, vous avez le proto, combien de temps pour mettre ca en prod?
                  - Oh, ben a peu près 6 mois pour mettre ce proto la en prod
                  - Comment ca? C'est quoi le problème de ce proto?
                  - Ben faut qu'on reparte de zero
                  - Hein?
                  - Ouais, on a prouvé que ca marchait avec une technologie qu'on veut pas utiliser, maintenant faut qu'on prouve que ca marche avec une techno qu'on veut utiliser
                  - …

                  Le concept du proto c'est de construire la base de la base sans ce qui va autour et qui est nécessaire a la production (logging, monitoring, marketing, ce genre de choses). Faire un proto pour le jeter et repartir de zero, c'est très stupide.

                  Il y a déjà un mode PROD.

                  Code smell. Pourquoi différencier la prod de ce que j'imagine être le dev?

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Montre ton code

          Posté par . Évalué à 3.

          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 ?

          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 ?
          C'est tout un tas de cas particuliers qui peuvent changer (ou non) par rapport à une exécution classique, et c'est pourquoi si mes pages web sont servit par une serveur distant, j'ai besoin de le savoir.

          Cela ne veut pas dire que je suis contre la simplicité. Si altas permet de commencer à coder sans s'en préoccuper, c'est très bien, et je comprend parfaitement l'argument. Mais la documentation sur ce type de détail technique est indispensable. C'est ce qui va faire la différence entre passer 3 jours pour fixer un bug incompréhensible ou passer 2h avant de comprendre une subtilité de l'implémentation de la lib.

          • [^] # Re: Montre ton code

            Posté par (page perso) . Évalué à 2. Dernière modification le 07/09/18 à 11:39.

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

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

            Toolkit Atlas : probablement le moyen le plus simple et le plus rapide pour ajouter une interface graphique à vos programmes Java, Node.js, Python… (voir page perso) !

            • [^] # Re: Montre ton code

              Posté par (page perso) . Évalué à 9. Dernière modification le 07/09/18 à 16:10.

              Je n'ai pas développé ce toolkit en ayant un type d'utilisateur en tête. […] 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).

              Si je comprends bien, tu développes un toolkit :

              • sans avoir d'utilisateur cible en tête,
              • sans connaitre les solutions standard du marché,
              • sans connaitre le positionnement de ta solution par rapport à l'existant,
              • donc sans savoir comment le reste de l'univers a adressé les problématiques que tu rencontres ou vas rencontrer, quelles sont les solutions apportées, quels sont les avantages, les inconvénients et comment tu te situes au-milieu de tout ça.

              Pour être tout à fait honnête, je ne comprends pas vraiment comment tu peux imaginer que ça fonctionne. Là tu es parti pour devoir réinventer la roue, sans jamais avoir vu de roue ni utiliser de roue. Je ne vois pas comment tu peux obtenir autre chose qu'un truc carré, et ce après t'être mangé tous les nids-de-poule que tous tes « concurrents » ont déjà bouchés sur leur propre route.

              Ça me fait penser à ce témoignage d'Olivier Levy. En gros, il a créé un site de vente de matériel son en ligne, alors que son boulot c'était le SEO, juste pour mettre en application ses techniques SEO. Il a choisi le matériel son plus ou moins au pif. Ça a marché… ou pas :

              Une entreprise bien huilée ? En apparence seulement, car la réalité vous rattrape. Plus Platine grossissait, plus je me rendais compte que je ne pouvais continuer à faire du commerce sur des produits que je ne connaissais pas.

              Et la liste des lacunes était grande:

              C’est un an après que je me suis rendu compte qu’on ne pouvait pas vendre de la sono sans aussi proposer des jeux de lumière…

              C’est seulement 2 ans après que je me suis rendu compte que je ne vendais pas les principales marques de sono et platine DJ… (Numark, Stanton, Gemini, Martin Light, etc…). En gros, c’était comme si j’avais ouvert une boutique de vente de téléviseurs sans proposer des marques comme Sony, Thoshiba ou encore Samsung…

              C’est seulement au bout d’un an que je me rends compte que le magazine papier dans lequel je faisais de la pub n’est plus du tout lu par les DJ, et que les nombres de publications qu’ils m’annonçaient étaient faux.

              Et je n’inclus pas les erreurs dont je ne me suis jamais rendu compte. Et puis toutes ces questions techniques auxquelles personne ne savait répondre chez nous… Autant de ventes perdues.

              Du coup si ton projet était une démonstration technologique, un essai de technologie ou une marotte, OK, c'est sans doute très intéressant. Mais j'ai l'impression que c'est plus que ça pour toi, du coup je ne comprends pas ta démarche.

              La connaissance libre : https://zestedesavoir.com

              • [^] # Re: Montre ton code

                Posté par (page perso) . É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…

                Toolkit Atlas : probablement le moyen le plus simple et le plus rapide pour ajouter une interface graphique à vos programmes Java, Node.js, Python… (voir page perso) !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.