Re: Montre ton code

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.

Zelbinium: pour la génération qui crée, pas celle qui scrolle...