Dokumentation zu JSL-VersionsänderungenIch bin sicher, dass wir alle schon Kunden mit diesem Problem getroffen haben ... Ein Kunde verwendet JMP 13 und weigert sich aus Gründen der JSL-Kompatibilität, auf neuere Versionen zu aktualisieren. Er sagt, er habe Tausende von Skripten, die aktualisiert werden müssten, und ihm sei nicht klar, welche Aktualisierungen erforderlich seien. Gibt es eine Dokumentation/Anleitung, in der beschrieben wird, wie ein JMP 13-Skript in 16+ konvertiert wird? Eine oberflächliche Suche ergibt nichts.
Betreff: Dokumentation zu JSL-VersionsänderungenNach einer umfassenden Suche konnte ich nur Folgendes finden: Neue Funktionen und Versionshinweise zu JMP® - JMP-Benutzer-Community
Diese Dokumentation deckt jedoch nicht alle aufgetretenen JSL-Änderungen ab (z. B. Spaltennamenverweise in JMP16) und auch keine Best Practices zur Konvertierung von JSL 13-Skripten in 16+.
Es scheint, als gäbe es eine Lücke in der Dokumentation zur Konvertierung von altem JSL ins neue, und dies wirkt sich auf die Akzeptanz neuerer JMP-Versionen bei den Kunden aus.
Betreff: Dokumentation zu JSL-VersionsänderungenHey! Änderungen am Skripting tauchten nicht immer in diesen Versionshinweisen auf. Eine zuverlässigere Quelle ist der Anhang mit den Kompatibilitätshinweisen des Skripting-Handbuchs. Dort erfahren Sie die meisten Fallstricke zwischen der Version, für die das Handbuch bestimmt ist, und der vorherigen Version. Sie müssten inkrementell vorgehen, um alles zu erhalten.
Allerdings hatte ich viele Kunden in dieser Situation und ich durchschaue sie normalerweise beim Bluff. Ich erinnere sie daran, dass sie zwei Versionen auf derselben Maschine haben können. Ich sage ihnen, sie sollen die neue neben der alten installieren und ihre kritischsten oder komplexesten Skripte auf der neuen Version ausführen und sehen, ob sie funktionieren. Wenn etwas kaputt geht, kümmern wir uns darum. Aber das Lustige ist – das ist noch nie passiert. Das Protokoll enthält möglicherweise einige Hinweise wie „Diese Funktion wird in einer zukünftigen Version entfernt.“ aber das Skript läuft immer noch. Die Entwickler haben solide Arbeit geleistet, um die Vorwärtskompatibilität in JSL aufrechtzuerhalten. Ich habe diese Strategie für Skripte verwendet, die bis zur Version 7 zurückreichen.
Das einzige Problem (jeder Art), auf das ich gestoßen bin, ist die Bit-Anpassung zwischen ODBC-Treiber und JMP. Aber das ist kein JSL-Problem. Wenn dieses Problem auftritt, wird ein eindeutiger Fehler im Protokoll ausgegeben. Aber ich glaube, 13 war die erste reine 64-Bit-Version. Das sollte also kein Problem sein.Betreff: Dokumentation zu JSL-VersionsänderungenJMP Development hat dasselbe Problem mit JMP! Neue Versionen der IDE, des Compilers oder der Codebibliotheken sowie Änderungen des Entwicklers am Quellcode können JMP beschädigen. Wir haben schon vor langer Zeit die branchenweit beste Unit-Test-Methode übernommen. Wir haben das JSL-Unit-Test-Framework, das wir intern verwenden, schon vor langer Zeit in der JMP-Community veröffentlicht. Wir führen jede Nacht nach dem täglichen Build Milliarden (OK, vielleicht nicht so viele) Tests durch, um Fehlerbehebungen und neue Funktionen zu überprüfen und sicherzustellen, dass keine Regressionen eingeführt wurden. Diese Tests sind vollständig automatisiert, oder wir können auch einzelne Tests durchführen.
Unternehmen, die auf JMP-Skripte angewiesen sind, sollten diese Vorgehensweise ebenfalls übernehmen. Sie verhindert zwar keine Fehler, hilft Ihnen jedoch dabei, diese zu finden, wenn Sie Skripte entwickeln oder ändern oder auf eine neue Version von JMP aktualisieren.
Die Entwicklung von Unit-Tests ist aufwändiger. Sie erfordert sorgfältige Überlegung und Konzeption und mehr Entwicklungszeit. Wir teilen den Programmier- und Testaufwand in JMP Development auf (eine weitere bewährte Methode). Dennoch verfügen Unternehmen möglicherweise nur über wenige JSL-Programmierer, sodass derselbe Entwickler Skripte und Unit-Tests schreiben kann.
Dokumentation ist unerlässlich. Wir unternehmen große Anstrengungen, um sie so nützlich wie möglich zu gestalten. Wie würden Sie eine vollständige Liste aller JSL-Änderungen in so vielen Versionen von JMP verwenden? Die Unit-Tests würden auf die Änderungen an dem JSL abzielen, das Sie tatsächlich verwenden. Das ist viel effektiver und praktischer.
Betreff: Dokumentation zu JSL-VersionsänderungenWenn Kunden so viele Skripte und Programme haben, ist es schade, dass sie nicht schon am Early Adopter-Programm teilgenommen haben. Neben Versionskontrolle und Unit-Tests ist dies die beste Möglichkeit, um zu prüfen, ob die Skripte auch in der nächsten Version noch laufen (selbst wenn das Unternehmen kein Upgrade durchführt, reicht zu Testzwecken eine einzelne Maschine zum Testen aus).
Aus Kompatibilitätsgründen erwarte ich mehrere Probleme von JMP 13 zu einer neueren Version, sobald sie Plattformelemente verwenden, um Werte, Umrisse und Ähnliches zu sammeln. Da einige Plattformen den Stil und die Struktur in den vergangenen Versionen geändert haben, wird dies mit Sicherheit auftreten.
Ich würde ihnen jedoch zunächst Best Practices für das Programmieren beibringen und sie dazu drängen, an den Treffen des Scripters‘ Club teilzunehmen. Auf dieser Seite finden Sie alle aufgezeichneten Sitzungen des European Scripters‘ Club der letzten 2,5 Jahre. Mit einigen Anleitungen und Best Practices-Sitzungen, aber auch mit einem vollständigen Lehrplan für 2023. Diese Sitzungen wurden von echten Benutzern aus unserem Kundenstamm geleitet und präsentiert, die in ihren Unternehmen für Schulungen, Automatisierung und mehr verantwortlich sind.
Betreff: Dokumentation zu JSL-VersionsänderungenHier ist eine weitere hervorragende Ressource: https://www.jmp.com/en_us/articles/unit-tests.html
