Script: compatibilité ascendante en généralPresque toutes les versions (depuis 7 ans), des clients m'appellent pour leur dire que leurs scripts ne fonctionnent plus dans la nouvelle version. Avez-vous des appels similaires?
Je me demande si nous pourrions avoir une meilleure vérification de la compatibilité ascendante pour les scripts personnalisés (pas ceux générés intégrés, où je suppose que nous avons cette vérification). Pour être clair, je ne parle pas de capacité de rétrogradation (mon script JMP 15 ne s'exécutant pas dans JMP 13), car les logiciels évoluent naturellement. Mais en tant que consommateur / utilisateur, j’attendrais qu’un script que j’écrive dans JMP 14 soit toujours exécuté dans JMP 15.
Je sais qu'adopter tôt est un moyen d'apprendre à connaître cela très tôt et d'envoyer les problèmes à la liste de diffusion. MAIS il y a un gros problème: les utilisateurs n'ont généralement pas le temps de faire une vérification de compatibilité chez les premiers utilisateurs, surtout s'il existe en version 7-9. Cela devrait être fait du côté du fournisseur du logiciel. C'est aussi ce dont se plaignent le plus souvent les clients. "Ce n'est pas leur travail" et j'avoue que je suis en partie d'accord avec lui (dans la plupart des cas).
Alors, avez-vous des plaintes similaires de la part des clients? Quel est notre processus actuel de vérification de la compatibilité ascendante? Il serait bon de rassembler ici quelques cas et suggestions sur ce qui pourrait être fait. (Et peut également en discuter lors d'une session de lancement avec les développeurs correspondants - je me souviens de la séance de questions / réponses en plénière où l'on pourrait aborder ces questions, mais le dernier était il y a trois ans, je crois - peut-on en parler uniquement aux SE en 2020? ).
Merci,
Martin
PS: La raison pour laquelle je mets cela en avant, un client industriel avec plus de 100 licences, est contrarié depuis des années qu’ils envisagent de passer de JMP à d’autres solutions, même open source - et qu’ils sont vraiment compatibles avec JMP depuis des années.
Re: Scripting: compatibilité ascendante en généralSalut Martin
FWIW, mon expérience est que le manque de compatibilité des transferts est lié presque toujours au fait d'extraire des éléments du rapport pour les manipuler davantage. Vous dites qu'il est raisonnable de s'attendre à ce que les logiciels «évoluent naturellement», mais, qu'on le veuille ou non, les modifications de la structure du rapport sont une conséquence presque inévitable de ce désir. Nous devrions toujours nous efforcer de signaler cela aux clients qui utilisent effectivement beaucoup les scripts.
Comme vous le savez, pour les logiciels utilisés en «production», il est très courant, voire même obligatoire, de disposer de zones de transfert dans lesquelles les logiciels mis à niveau sont minutieusement testés avant de les rendre «vivants». Cette discipline pourrait être perçue comme étant en contradiction avec le fait que JMP n'est «qu'un» logiciel de bureau, mais (comme votre message l'illustre), les risques sont réels et nous devrions aider les utilisateurs à voir JMP de cette manière lorsque leurs habitudes d'utilisation l'exigent.
En bref, cette tension est un effet secondaire du fait que JMP est très fonctionnel. Je pense que nous pouvons et devrions mieux alerter nos clients sur les risques et les conséquences de ne pas donner à une base de code JSL significative l’appui de bonnes pratiques en matière de génie logiciel industriel. La R & D "pourrait" fournir des méthodes pour obtenir toutes les valeurs requises de manière indépendante du rapport, mais cela ne figure dans aucune feuille de route, et dans tous les cas, cela enlèverait une partie de la flexibilité que les programmeurs de JSL semblent apprécier. très.
Comme vous, je serais très intéressé d’entendre d’autres exemples de problèmes survenus à ce sujet. . .
À votre santé,
Ian
Re: Scripting: compatibilité ascendante en généralSalut, Martin!
TL; DR:
Point 1: Les sauts de code entre les versions sont généralement dus au fait que les utilisateurs ne suivent pas les meilleures pratiques de JSL et ne scriptent pas de manière défensive. Point 2: Il incombe toujours au client de valider les performances logicielles (locales ou autres) entre les versions. Ils doivent le traiter comme n'importe quel autre outil de fabrication - qui est entièrement vérifié avant d'être mis en production.
La version longue:
Juste pour commenter le commentaire @ian_jmp made - La plupart des interruptions de code entre les versions sont dues au fait que certaines personnes ne suivent pas (ou ne suivent pas) les meilleures pratiques de JSL. Il est beaucoup plus facile de casser le code qui fonctionne mais qui n'est pas bien pensé. Mark Bailey appelle cela «le script défensif». L'exemple de Ian, qui tire des rapports existants, est classique, en particulier s'il souscrit l'intégralité de l'arborescence d'affichage. La meilleure pratique consiste à utiliser un nom de zone de contour comme repère local, puis un indice (car ils ne changent pas aussi souvent).
J'ai également rencontré quelques cas dans lesquels des personnes (moi-même inclus) construisaient JSL qui s'appuie sur une fonctionnalité qui subit une refonte entre les versions. Pour moi, les modifications apportées à Recode dans JMP 14 ont cassé une partie d'un complément que je maintenais. Dans ce cas, j'ai fait quelque chose pour que le code fonctionne et j'ai été brûlé. Un autre exemple (client) est celui où une personne utilisait des noms non conformes à ODBC dans sa base de données. Lorsque nous avons appliqué ODBC entre les versions, les scripts ont éclaté. Ici, quelqu'un n'a pas suivi les normes et ils ont été brûlés pour cela. Le problème, c'est que vos clients risquent moins de rencontrer des problèmes s'ils créent un code conforme à nos meilleures pratiques en matière de rédaction de JSL. S'ils le font, il est assez rare que JSL transforme une version à l'autre. La plupart des choses que j'ai écrites avec un état d'esprit relatif aux scripts défensifs sont assez robustes - mais je vérifie toujours que tout fonctionne correctement. J'attends généralement les deux dernières versions des premiers utilisateurs à tester (les modifications apportées à JMP sont généralement assez stables à ce stade).
Ian a également fait valoir un très bon argument pour passer d'une version à l'autre. Aux États-Unis, certaines industries sont fortement réglementées (industrie pharmaceutique, biotechnologie, finances et industrie manufacturière avec des applications de sécurité militaire ou nationale). Ces industries ont des exigences de validation pour tout nouveau logiciel ou les nouvelles versions de logiciel, qui obligent les utilisateurs à documenter qu'ils ont vérifié le bon fonctionnement du logiciel et à fournir des résultats cohérents entre les versions. Mes autres clients savent qu'ils doivent vérifier leur code entre les versions. Je pense donc que c’est vraiment le problème de maturité et de discipline dans la culture de l’entreprise chez ce client (ou du moins avec les personnes qui y génèrent la JSL). Le flux de travaux de test mentionné par Ian (mise en scène, puis mise en production) est une pratique courante dans tous les secteurs avec lesquels j'ai travaillé (aux États-Unis, dans l’Union européenne ou en Asie).
En résumé, si leur JSL est critique, ils doivent le traiter comme tout autre logiciel de production et valider la version de JMP (avec le JSL critique) avant de le mettre en production. Je parie que vos plaintes proviennent principalement de membres de la communauté des ingénieurs qui ne comprennent pas comment cela fonctionne. Vous pouvez leur demander s’ils lancent un nouvel équipement en production avant de tester de manière approfondie les performances de cet outil et de les faire correspondre aux autres éléments - ils répondent «non». Vous pouvez alors indiquer que le logiciel est un outil qui traité de la même manière.
Pensée de suivi
Pensez-y davantage - si les gens respectent la meilleure pratique JSL (utilisation de fonctions et d’expressions, de la portée, des espaces de noms, etc.) commentant fortement leur code , etc.) il est plus facile de déboguer quand les choses se cassent (ce qu’elles font). On dirait donc que le client en question a un JSL fragile mal formé, qui s'est développé de manière organique au fil du temps. C'est probablement horriblement commenté et la personne qui l'a écrit est passé ou n'a pas la moindre idée de comment le réparer (j'appelle ces scripts franken) ... Dans ce cas, je recommanderais qu'ils envoient quelqu'un qui connaît JSL aux cours SAS Ed JSL SAS pour un rappel des meilleures pratiques, puis les lâche pour moderniser le code en question et met en place des procédures d'exploitation normalisées pour ajouter le JSL en question. à leurs plans de test de validation logicielle.
Re: Scripting: compatibilité ascendante en généralJe suis d'accord avec tous les commentaires jusqu'à présent. Je vois tout le temps un code de «production» qui est horrible. Je ne peux pas croire que cela fonctionne dans la version actuelle, encore moins avoir un espoir dans l'avenir. Ces utilisateurs n'ont pas appris à écrire des scripts JMP. C'est différent de la programmation informatique générale. Ce n'est pas juste la syntaxe. Ils viennent de pirater. (J'utilise le terme 'pirate informatique' avec vénération. Cette activité est différente.) Ils ne savent pas ce qu’ils font.
En ce qui concerne le commentaire sur les modifications de l'interface utilisateur JMP qui empêchent d'accéder à la couche de rapport, de nombreux utilisateurs ne pratiquent pas le codage sécurisé. Il existe des moyens de minimiser ou d'éliminer ces problèmes, mais leur méthode produit un code fragile.
Re: Scripting: compatibilité ascendante en généralMerci jusqu'ici pour vos commentaires. Je suis d'accord avec tous vos points concernant les tests avant de passer en production et le codage de sauvegarde / défensif (bien que les utilisateurs ne l'aimeront probablement pas;)). Ceci est définitivement sous la responsabilité de l'utilisateur et de l'entreprise utilisant des scripts dans n'importe quel langage.
Cependant, je souhaite faire avancer la discussion également avec un point de vue plus critique (- à la fin, j'espère que nous aurons au mieux un message commun à nos clients et un processus d'automatisation plus robuste à vendre à nos clients):
Venant d'une entreprise de logiciels qui s'appuie sur le langage de programmation sur lequel l'outil est construit, je suis étonné de la fréquence à laquelle je découvre que JSL change de version. Dans ma vie passée, ces problèmes ne concernaient que des fonctions et des fonctions non documentées, et non des paramètres et des options telles que les thèmes de couleur et d'autres éléments des arborescences ou des méthodes. De plus, toutes les fonctions ont été documentées dans toute leur étendue: quels entrées et sorties sont disponibles, quelles sont la description et la définition de cette option / entrée / sortie et ainsi de suite. Le guide de script et l'index ne sont pas tous les deux de ce type. Plus c'est l'appel de base et toutes les autres options possibles que vous devez découvrir vous-même.
On pourrait dire que toute partie non documentée est sujette à changement - ce serait la réponse facile. Mais je crois que ce n'est pas si facile. La plupart du temps, nous devons changer au moins un peu "le niveau inférieur aux fonctionnalités intégrées". Nous ne fournissons pas de documentation concrète indiquant "c'est ce que vous pouvez faire" et "tout le reste n'est pas pris en charge" (alias may fonctionne maintenant mais est sujet à modification).
Un langage de programmation devrait avoir un tel cadre - ou nous disons que JSL n'est pas un tel langage et soyez plus prudent avec notre promotion actuelle de créer des applications pour toucher plus d'utilisateurs, car il est facile de construire du code reproductible mais il se peut qu'il ne soit pas aussi fiable. pour les futures versions.
Je serais curieux d’entendre ce que les autres pensent de cela (j’admets le point de vue critique et le but le plus important qui soit, encore une fois pour susciter une discussion diversifiée sur ce sujet), peut-être aussi l’un ou l’autre développeur qui fait cela base de jour.
Re: Scripting: compatibilité ascendante en généralVotre dernier point est le point critique - JSL est incroyablement puissant, mais au fond ce n’est pas un «langage de programmation», c’est un langage de script ou de macro. Il a des structures qui ressemblent à la programmation orientée objet, et il peut être utilisé de cette façon dans une certaine mesure, mais il est construit sur JMP et a toujours été conçu pour automatiser des tâches dans l’interface graphique ou pour étendre celle-ci. Beaucoup de gens oublient que - ce qui signifie également qu'ils oublient quand les choses changent dans le produit - des choses peuvent se briser dans JSL (surtout s'ils ne les codent pas bien). Nous ne devrions pas parler de JSL comme C ++, etc. À proprement parler, même Python et R sont des langages de programmation plus proches que JSL. Certaines personnes sont peut-être désorientées parce que la ligne est floue avec les macros Excel et VBA. Cependant, il est clair que JSL est un langage de script différent du langage de programmation.
Meilleur,
M
Re: Scripting: compatibilité ascendante en généralSalut Mike,
D'accord, c'est une langue de script et il faut donc y marcher. J'ai trouvé cette discussion intéressante, car elle met également en évidence certains aspects supplémentaires sur lesquels nous devrions toujours guider les utilisateurs lorsqu'ils doivent commencer à automatiser ou à écrire leurs processus. Avons-nous - outre le cours de formation JMP JSL - d'autres références relatives à JMP pour les scripts "défensifs"?
La plupart des références trouvées sur le Web concernent d’autres langues et ne sont pas liées à JMP (bien que vous puissiez les utiliser aussi, bien sûr). Les webcasts Mastering JMP ne couvrent pas un bon style de programmation / script. Peut-être un sujet intéressant également pour une présentation découverte?
Re: Scripting: compatibilité ascendante en généralJe pense que nous pourrions nous améliorer dans ce domaine. Il y a beaucoup d'informations sur la communauté, dans les cerveaux du personnel, dans les livres et dans la documentation, mais il n'y a pas vraiment de document sur les «meilleures pratiques» à ma connaissance. Il devrait y avoir. Je pense qu'une grande partie de la consternation que vous vivez sur le terrain peut être attribuée à ce point.
@ian_jmp - Peut-être que ce serait quelque chose que la communauté technique pourrait faire comme barre latérale lors du coup d'envoi.
Meilleur,
M
Re: Scripting: compatibilité ascendante en généralComme ma réponse l’a laissé entendre, j’estime qu’il s’agit d’un domaine dans lequel nous pourrions faire mieux, d’autant plus que nous encourageons généralement les applications de construction en tant que composante de la partie «expansion» de notre stratégie «terrains et expansion».
FWIW, mon point de vue personnel est que toutes les SE ne doivent pas maîtriser la JSL à moins d’être si enclines à le faire. Mais je crois que chaque SE doit savoir ce qui est possible et, parallèlement, quelles sont les bonnes pratiques et les inconvénients de ne pas y adhérer.
Malheureusement, le coup d'envoi de 2020 est un peu comprimé et la piste technique est déjà organisée. Nous allons donc trouver un autre moyen de gérer cela. Plus tard.
Re: Scripting: compatibilité ascendante en généralNous avons commencé à ajouter des suggestions explicites de "meilleures pratiques" dans nos cours de scripting, il y a plusieurs éditions. Nous continuons d’étendre et d’affiner ces suggestions à chaque révision. Nous recevons des commentaires positifs des étudiants. Eh bien, au moins parmi les étudiants qui ne sont pas pressés de se détourner.
