L'un des plus grands défis rencontrés lors du développement de JMP au sein d'une organisation est l'apprentissage du JSL, et la prolifération du code JSL au sein de l'organisation. L'un des plus grands défis qui se pose avec l'adoption de JMP à grande échelle est la question de savoir comment gérer l'ensemble du code généré par les utilisateurs à grande échelle. Comment contrôler tout cela ?
Au fil des ans, de nombreuses méthodes ont été proposées pour y parvenir. Certaines proviennent de l'informatique et du développement logiciel, ainsi que des systèmes de contrôle de version. D'autres proposent d'utiliser simplement un lecteur partagé. Il s'avère que chacune présente des avantages et des inconvénients.
Pour vous éclairer un peu, il existe une solution intermédiaire qui fonctionne plutôt bien pour ce problème… Je ne souhaite pas consacrer toutes mes ressources à la création d'une véritable société de développement logiciel en interne pour gérer la gestion logicielle. Je ne veux pas gérer le Far West, qui se résume à un simple disque partagé sur le serveur de quelqu'un.
Mais il s'avère que ces deux extrêmes ont leurs avantages et leurs inconvénients. Lorsqu'on parle de Git ou de système de gestion de versions, GitHub est généralement celui que l'on connaît le mieux. Gérer des bases de code ? C'est précisément ce qu'il fait avec brio. C'est un excellent outil.
Déployer facilement des mises à jour ? Ce n'est pas son domaine de prédilection. Ce n'est pas sa vocation. Il est conçu pour le développement logiciel professionnel, et ce n'est pas de cela dont il est question ici. Il n'est pas particulièrement performant dans ce domaine.
Contrôler les accès et les autorisations de version est bien sûr une tâche particulièrement efficace. Assurer le contrôle des versions et suivre les modifications au fil du temps : tout cela est précisément ce pour quoi ces systèmes de contrôle de version sont conçus. De ce fait, ils ne sont pas adaptés aux débutants. Ils sont conçus pour les professionnels.
J'ai vu des exemples concrets d'utilisation de cette technologie, mais il s'agit généralement d'organisations qui consacrent du temps, des ressources et des personnes à la création d'une équipe dédiée au développement logiciel. Cela peut fonctionner dans certaines situations, ou l'entreprise peut déjà l'avoir pour d'autres raisons.
À l'autre extrême, l'idée d'utiliser uniquement des fichiers JSL et un dossier ou un répertoire partagé sur un serveur est presque identique à celle des systèmes de contrôle de version. La gestion du code source n'est pas optimale. Certains systèmes cloud s'améliorent, mais la situation reste délicate.
Déployer facilement les mises à jour ? Bien sûr. Il suffit de cliquer sur la dernière mise à jour. Vous pouvez envoyer un e-mail ou utiliser des modules complémentaires. Certains codes proposés au fil du temps pour faciliter ce processus particulier peuvent être intégrés à vos modules complémentaires. C'est tout à fait possible, mais pas anodin. Mieux que le système de gestion de versions sur ce point.
Contrôle d'accès ? Pas terrible, pour être honnête. Adapté aux novices ? Oui. Ce n'est pas mal, mais ce n'est pas non plus exceptionnel. Il s'avère qu'il existe un juste milieu. Mon collègue, mon co-auteur et moi-même avons abordé ce sujet à partir de deux activités de développement différentes. Nous avons tous deux plus ou moins abouti à la même solution. C'était intéressant de voir comment nous avons trouvé un terrain d'entente sur cette idée.
Il s'avère que l'idée est OneDrive, croyez-le ou non. Tout le monde l'a. C'est un système d'entreprise. Enfin, pas tout le monde, mais une bonne partie des organisations ont accès à OneDrive ou à un équivalent, disons. Je vais utiliser OneDrive pour cette session, car c'est ce que j'ai, mais il existe des équivalents.
Les avantages de cette approche sont toutefois vraiment surprenants. La gestion du code source est similaire à celle du JSL, mais avec un meilleur contrôle des versions et des modifications, et la possibilité de suivre l'historique et de revenir à des versions antérieures. En cas de problème, de corruption du code ou autre, nous pouvons revenir en arrière. Ces fonctionnalités sont offertes par les systèmes d'entreprise dont nous parlons ici.
Déployez facilement les mises à jour. C'est là que cette solution entre en jeu. Nous pouvons mettre en place une stratégie de mise à jour quasi automatisée pour toute une entreprise, sans avoir à lever le petit doigt, en réalité. C'est quasiment sans code. Il y a quelques éléments de code à intégrer à nos modules complémentaires, mais au-delà, tout se fait en un clin d'œil. C'est incroyablement simple à mettre en œuvre avec ces systèmes.
Contrôler et modifier les autorisations. Là encore, ces autorisations sont intégrées. Vous pouvez autoriser les utilisateurs à consulter et à modifier les autorisations de téléchargement. Vous pouvez leur accorder un accès complet selon vos besoins, et les activer ou les désactiver selon vos besoins. Vous pouvez le faire pour les groupes. Des options de politique sont disponibles, entre autres.
Il dispose d'un excellent système d'autorisations d'accès et est adapté aux débutants. Comme je l'ai dit, très peu de codage supplémentaire est requis. Si vous développez déjà des modules complémentaires, vous savez tout ce qu'il faut pour le faire. C'est extrêmement facile à mettre en œuvre.
Quel est le problème ? Eh bien, le problème vient du fait que lorsque JMP installe un module complémentaire, celui-ci n'est en fait qu'un dossier contenant du JSL, quelques fichiers spéciaux indiquant à JMP où le placer dans l'interface graphique, ainsi que des métadonnées le concernant. Mais la plupart du temps, il s'agit simplement d'un dossier de fichiers JSL que JMP récupère et place à un emplacement précis.
Ce qui est intéressant, c'est que les fichiers importants du module complémentaire peuvent se trouver n'importe où accessible par JMP. Ils ne sont pas forcément dans ce dossier. Vous pouvez les placer où vous le souhaitez. Hyde et moi avons réalisé qu'il était impossible de placer les fichiers importants dans un dossier OneDrive, puis d'utiliser un simple pointeur du module complémentaire pour y accéder et les ouvrir dans ce dossier.
Il s'avère que rien ne vous empêche de le faire. Voici le résultat. Deux diapositives, la suivante et la suivante, serviront de référence pour plus tard, mais nous allons les parcourir rapidement pour avoir une brève narration.
Dans OneDrive sur le cloud, le dossier OneDrive contiendra l'essentiel du module complémentaire. Nous aurons l'interface utilisateur et le code du module complémentaire. C'est ainsi que Hyde l'a abordé. Moi, je partais de l'idée de placer des ressources, de grandes bibliothèques de documents qui occuperaient beaucoup d'espace sur le disque dur d'un utilisateur, et qu'il n'aurait besoin de récupérer qu'au moment de les ouvrir. Sinon, il ne voudrait pas occuper trop d'espace sur son disque dur. Tout cela peut exister dans le dossier OneDrive, et c'est là qu'il se trouve.
Sur le bureau JMP se trouve un minuscule script, d'une vingtaine de lignes environ. Son rôle principal est de le rendre lisible par l'utilisateur. Il effectue trois tâches spécifiques. Premièrement, il vérifie l'emplacement des fichiers de compléments. A-t-il un emplacement ? Sinon, il doit afficher une boîte de dialogue indiquant : « Où dois-je chercher le complément ? » Ensuite, il ouvre le package du complément. C'est tout ce qu'il fait. Ces trois tâches.
L'autre élément présent sur votre disque dur utilisateur est ce que j'appelle un miroir de l'emplacement OneDrive. Selon sa configuration, ce miroir peut soit contenir uniquement des liens logiques, des liens vers des fichiers, des alias (si vous les connaissez), soit des copies des fichiers synchronisés. Ces deux méthodes présentent des avantages et des inconvénients, mais elles fonctionnent toutes deux aussi bien.
Première option : vous n'avez que des liens logiques. Avantages : taille de fichier très réduite. Cela occupe peu d'espace sur le disque dur. Il s'agit simplement de liens, et les fichiers sont extraits au moment de l'exécution. Vous obtenez des informations de fichier précises et à jour. Inconvénients : cela ne fonctionne pas sans connexion Internet. Si vous êtes en avion ou dans un endroit similaire, et que vous n'avez pas de Wi-Fi, vos modules complémentaires risquent de ne pas se charger du tout.
L'autre inconvénient est que, selon la taille du module complémentaire, il peut y avoir un léger décalage entre le clic sur le lien dans JMP et l'ouverture du module. Ce sont deux inconvénients. Je ne dirais pas que c'est un inconvénient, mais il faut savoir que pour les modules plus volumineux, un léger décalage peut survenir.
La deuxième option, que je vais vous montrer aujourd'hui, est la synchronisation des dossiers. Cette option occupe plus d'espace sur le disque dur, mais permet un accès hors ligne et le chargement est… certes, mais il est nettement plus rapide. Si une version plus récente d'un fichier doit être récupérée et qu'il n'est pas encore synchronisé, un léger décalage peut survenir. L'avantage est que les fichiers modifiés sont automatiquement copiés dans votre dossier local.
Dans les deux cas, les autorisations de contrôle de version en lecture/écriture sont toujours en place. Si quelqu'un effectue une modification sur son disque dur local, une copie du fichier est créée. Elle ne permet pas de modifier l'original et ne fait que référencer celui-ci. Si quelqu'un modifie quelque chose et commet une erreur, au prochain chargement du module complémentaire, il chargera l'original. Il ne chargera pas sa modification. Ce contrôle de version, ce flux de travail protégé, est en place quoi qu'il arrive.
Pour configurer cet emplacement OneDrive, plusieurs méthodes s'offrent à vous. La plus simple que j'ai trouvée est Teams. C'est d'ailleurs par là que nous allons commencer la démonstration de cette session. Dans Teams, si vous créez une équipe, le site SharePoint dont vous avez besoin est automatiquement créé. Vous pouvez ensuite y ajouter un dossier depuis Teams et configurer la synchronisation à partir de là.
Vous pouvez ensuite accéder au site SharePoint si vous le souhaitez. Vos utilisateurs peuvent le faire directement sur le site SharePoint et y configurer la synchronisation. Vous pouvez ensuite leur accorder des autorisations de consultation, de modification, de téléchargement, etc. Vous pouvez également leur donner des autorisations d'accès au contenu et contrôler l'accès au module complémentaire. C'est pratique. Voyons comment procéder rapidement.
Voici Teams. J'ai Teams. Je suis dans mon groupe Teams, juste ici. On y accède et il y a un bouton, généralement petit, qui s'affiche. Il y a un bouton « Créer une équipe ». On crée une équipe et on crée le canal. Ensuite, quand on accède au canal, en dessous, il y a une option « Fichiers ».
Vous pouvez créer un nouveau fichier ou un nouveau dossier. En général, je crée un dossier que je nomme « Contenu du complément ». De là, je peux utiliser mes petits points, et j'ai des options pour télécharger ou synchroniser avec mon SharePoint. Je veux ouvrir mon SharePoint Drive. Voici mon SharePoint Drive. C'est le même emplacement. Je suis dans ce dossier. Voici le contenu du complément. Voici l'essentiel de mon complément que je vais vous montrer.
Sous ces trois points, il y a une option « Synchroniser ». Son effet sur mon système de fichiers est différent sous Windows, mais sur Mac, il crée un emplacement pour les bibliothèques partagées et une copie du dossier à cet emplacement.
Maintenant, lorsque j'apporte des modifications à ce dossier, comme je dispose des droits de modification, toutes les autres personnes y ayant accès reçoivent automatiquement une copie de ces modifications. Elles sont transférées vers le site SharePoint, puis vers tous les autres utilisateurs. C'est ici que je commence mes modifications.
Maintenant, examinons rapidement le fichier. Celui-ci n'est pas vraiment important. Il s'agit simplement de son contenu. Voyons à quoi ressemble l'un d'eux. Il s'agit du module complémentaire que j'ai créé, et je vais vous expliquer… Je ne vais pas vous expliquer comment créer le module complémentaire lui-même, car il s'agit simplement d'utiliser l'assistant de création de module complémentaire.
Voyons ce que nous avons ici. Voici les éléments qui ne nous intéressent pas vraiment. Ce sont ceux que JMP doit connaître. Le lanceur de modules complémentaires et les préférences de modules complémentaires sont les deux éléments qui nous intéressent. Les préférences de modules complémentaires contiennent un dossier ou un fichier. Je vais le placer ici sans le sélectionner, car il a été supprimé lors de mes tests l'autre jour.
C'est comme ça que ça devrait se passer par défaut. Ce script shell va me demander : « Où se trouve le contenu de ce module ? » Une fois cette information trouvée, il l'écrira dans ce script de préférences. Ainsi, je n'aurai pas à la demander à chaque exécution du module. Il me la posera une fois et s'en souviendra.
Voyons voir. Je vais partager ce script shell très rapidement. Laissons tomber le blog. Il y a trois petits morceaux de code, encore une fois, très courts. Il n'y a pas grand-chose à voir ici. Une boîte de dialogue permet de savoir où se trouve réellement le JSL de ce module complémentaire. Essayez d'ouvrir les préférences. Ensuite, une boucle tente d'ouvrir le code ou me demande où il se trouve. C'est tout ce que nous allons voir ici.
J'ai créé ce module complémentaire et je l'ai placé dans mon dossier « Compléments ». Si j'ouvre JMP et que je sélectionne « Démo », le message suivant s'affichera : « Hé… » Vous ne le voyez pas ici, mais il indique : « Veuillez sélectionner votre répertoire pour le module de démarrage de la formation. » Enfin, pour ce module complémentaire… J'ai oublié de modifier ce texte. Il me suffit d'aller dans le dossier « Voici mon lecteur partagé » et « Voici où se trouve mon dossier ». Je réponds : « OK, ouvrez ». Le module complémentaire a été lancé depuis OneDrive.
Je peux revenir ici, rouvrir ce fichier et obtenir un texte différent pour ce fichier de complément. J'ai ajouté le complément. Je vais l'exécuter à nouveau. Le nouveau texte s'affiche maintenant en bas. Pour vous donner une idée de la complexité, je vais vous montrer rapidement deux compléments différents qui exploitent tous deux cette fonctionnalité. Je ne vais pas les détailler. Je vais conclure. Voici ce que je veux.
Le premier est celui que j'ai créé, appelé JMP on the Spot. Il utilise le concept dont nous parlons aujourd'hui pour extraire le contenu d'un navigateur web ou d'un visualiseur. Un référentiel ou une bibliothèque serait probablement une meilleure description. Si nous ouvrons JMP on the Spot, tout ce contenu existe uniquement dans le cloud. Si je souhaite l'ouvrir, il sera téléchargé en temps réel.
Une autre option est celle que nous, les ingénieurs logiciels, utilisons pour gérer nos ressources lors de l'apprentissage d'une nouvelle version, ce qui est particulièrement adapté à JMP 19. Mais c'est là que nos ressources sont stockées. Elle utilise exactement ce module complémentaire. Cette interface graphique et tout ce qui lui est associé sont hébergés sur OneDrive.
Si nous devions y jeter un œil, je l'aurais ici. Tout ce qui existe dans le module complémentaire sur mon disque dur est le fichier de préférences que nous avons déjà vu, et c'est précisément le fichier que je vous ai montré pour l'exemple de démonstration. Tout le reste est en temps réel. Je l'ai téléchargé sur mon disque dur pendant que l'équipe le modifie.
Au fur et à mesure que nos supports pour JMP 19 et JMP 18 sont téléchargés, ils sont transférés sur OneDrive et automatiquement transférés sur mon ordinateur. Je n'ai plus à me soucier de la mise à jour de mes modules complémentaires, des vidéos et autres contenus volumineux que nous recevons parfois lors de nos formations. Ils sont hébergés dans le cloud, je n'ai pas besoin de les télécharger. Je n'en prends pas de place sur mon disque dur.
Qu'avons-nous vu aujourd'hui ? Nous avons vu que OneDrive permet de gérer la base de code, de déployer facilement les mises à jour et de contrôler les accès et les autorisations. De plus, il est facile à utiliser pour les débutants. Très peu de code supplémentaire est requis, sauf si vous écrivez votre propre JSL. Vous savez déjà tout ce qu'il faut savoir pour cela. Il suffit de se rappeler qu'aucune règle n'oblige le module complémentaire à résider dans le référentiel de modules complémentaires.
