Documentation sur les changements de version JSLJe suis sûr que nous avons tous rencontré des clients avec ce problème... un client utilise JMP 13 et refuse de passer à des versions plus récentes pour des raisons de compatibilité JSL. Il dit qu'il dispose de milliers de scripts qui devraient être mis à jour et qu'il ne sait pas exactement quelles mises à jour sont nécessaires. Avons-nous une documentation/des conseils précisant comment convertir un script JMP 13 en 16+ ? Une recherche rapide ne donne rien.
Re : Documentation sur le changement de version JSLAinsi, après une recherche exhaustive, la seule chose que j'ai pu trouver est ceci : Nouvelles fonctionnalités et notes de version de JMP® - Communauté d'utilisateurs JMP
Mais cette documentation ne couvre pas toutes les modifications JSL survenues (par exemple, les références de nom de colonne dans JMP16), ni les meilleures pratiques de conversion des scripts JSL 13 en 16+.
Il semble qu'il y ait une lacune dans la documentation pour la conversion de l'ancien JSL en nouveau, et cela a un impact sur l'adoption par les clients des nouvelles versions de JMP.
Re : Documentation sur le changement de version JSLJMP Development a le même problème avec JMP ! Les nouvelles versions de l'EDI, du compilateur ou des bibliothèques de code, ainsi que les modifications apportées par les développeurs au code source, peuvent interrompre JMP. Nous avons adopté il y a longtemps les meilleures pratiques de tests unitaires du secteur. Nous avons publié il y a longtemps le framework de tests unitaires JSL que nous utilisons en interne sur la communauté JMP. Nous effectuons des milliards (OK, peut-être pas tant que ça) de tests chaque nuit après la construction quotidienne pour vérifier les corrections de bugs et les nouvelles fonctionnalités et qu'aucune régression n'a été introduite. Ces tests sont entièrement automatisés ou nous pouvons également exécuter des tests individuels.
Les entreprises qui dépendent des scripts JMP devraient également adopter cette pratique. Il n'empêche pas les bugs mais vous aide à les trouver lorsque vous développez ou modifiez des scripts ou effectuez une mise à niveau vers une nouvelle version de JMP.
Développer des tests unitaires demande plus de travail. Cela nécessite une réflexion et une conception minutieuses et plus de temps de développement. Nous divisons les efforts de programmation et de test dans JMP Development (une autre bonne pratique). Néanmoins, les entreprises peuvent ne disposer que de quelques programmeurs JSL afin que le même développeur puisse écrire des scripts et des tests unitaires.
La documentation est essentielle. Nous consacrons beaucoup d'efforts pour le rendre aussi utile que possible. Comment utiliseriez-vous une liste exhaustive de toutes les modifications JSL dans autant de versions de JMP ? Les tests unitaires cibleraient les modifications apportées au JSL que vous utilisez réellement. C'est beaucoup plus efficace et pratique.
Re : Documentation sur le changement de version JSLSi les clients ont autant de scripts et de programmes, il est dommage qu'ils n'aient pas déjà participé aux premiers utilisateurs. Outre le contrôle de version et les tests unitaires, c'est le meilleur moyen de vérifier si les scripts seront toujours exécutés dans la prochaine version (même si l'entreprise ne procédera pas à la mise à niveau, à des fins de test, une seule machine sur laquelle tester serait suffisante.
Du point de vue de la compatibilité, je m'attends à plusieurs problèmes de JMP 13 vers une version plus récente dès qu'ils utilisent des éléments de plate-forme pour rassembler des valeurs, des contours et autres. Comme certaines plates-formes ont modifié le style et la structure dans les versions précédentes, cela apparaîtra certainement.
Cependant, je commencerais à les guider vers les meilleures pratiques de codage. Et poussez-les à participer aux réunions du Scripters' Club. Sur cette page, vous trouverez toutes les sessions enregistrées au cours des 2,5 dernières années du European Scripters' Club. Avec quelques sessions de guidage et de bonnes pratiques mais aussi avec un programme complet en 2023. Ces sessions ont été gérées et présentées par des utilisateurs réels de notre clientèle qui sont responsables de la formation, de l'automatisation et plus encore dans leur entreprise.
Re : Documentation sur le changement de version JSLVoici une autre excellente ressource : https://www.jmp.com/en_us/articles/unit-tests.html
Re : Documentation sur le changement de version JSLHé! Les modifications apportées aux scripts n'apparaissaient pas toujours dans ces notes de version. Une source plus fiable est l'annexe des notes de compatibilité du guide de script. Cela vous indiquera la plupart des pièges entre la version pour laquelle le guide est destiné et la version précédente. Il faudrait progresser pour tout obtenir.
Cela dit, j'ai eu beaucoup de clients dans ce bateau et j'ai généralement tendance à bluffer. Je leur rappelle qu'ils peuvent avoir deux versions sur la même machine. Je leur dis d'installer le nouveau avec l'ancien, d'exécuter leurs scripts les plus critiques ou les plus complexes sur la nouvelle version et de voir s'ils fonctionnent. Si quelque chose se brise, nous nous en occuperons. Mais ce qui est drôle, c'est que rien ne l'a jamais été. Le journal peut contenir une mention « cette fonctionnalité sera supprimée dans la prochaine version ». notes, mais le script s'exécute toujours. Les développeurs ont fait un travail solide en maintenant la compatibilité ascendante dans JSL. J'ai utilisé cette stratégie pour des scripts créés dès la v7.
Le seul problème (de quelque nature que ce soit) que j'ai rencontré est la correspondance du pilote ODBC avec le nombre de bits JMP. Mais ce n'est pas un problème JSL. Lorsque ce problème se produit, une erreur claire est générée dans le journal. Mais je pense que la version 13 était la première version 64 bits uniquement. Cela ne devrait donc pas poser de problème.
