Scripting: Aufwärtskompatibilität im AllgemeinenFast jede Veröffentlichung (seit 7 Jahren), in der Kunden mir mitteilen, dass ihre Skripte nicht mehr funktionieren, funktioniert in der neuen Version nicht mehr. Erhalten Sie ähnliche Anrufe?
Ich frage mich, ob wir eine bessere Aufwärtskompatibilitätsprüfung für benutzerdefinierte Skripte haben könnten (nicht die eingebauten generierten, bei denen wir diese Prüfung wahrscheinlich haben). Um es klar auszudrücken, ich spreche nicht über die Rückwärtsfähigkeit (auch bekannt als mein JMP 15-Skript, das nicht in JMP 13 ausgeführt wird), da sich die Software natürlich weiterentwickelt. Aber als Verbraucher / Benutzer würde ich erwarten, dass ein Skript, das ich in JMP 14 schreibe, immer noch in JMP 15 ausgeführt wird.
Ich weiß, Early Adopter ist eine Möglichkeit, dies frühzeitig zu erfahren und die Probleme an die E-Mail-Liste zu senden. ABER es gibt ein großes Problem: Die Benutzer haben in der Regel nicht die Zeit, eine Kompatibilitätsprüfung für den frühen Anwender durchzuführen, insbesondere dann nicht, wenn es 7-9 Versionen davon gibt. Dies sollte auf der Seite des Softwareanbieters erfolgen. Darüber beschweren sich die Kunden meistens. "Es ist nicht ihre Aufgabe" und ich muss zugeben, dass ich ihr teilweise zustimme (in den meisten Fällen).
Haben Sie ähnliche Beschwerden von Kunden? Was ist unser aktueller Prozess zur Überprüfung der Aufwärtskompatibilität? Es wäre schön, hier einige Fälle und Vorschläge zu sammeln, was getan werden könnte. (Und kann dies auch während einer Kick-Off-Sitzung mit den entsprechenden Entwicklern besprechen - ich erinnere mich an die Fragen und Antworten im Plenum, in denen man sich mit diesen Dingen befassen konnte, aber die letzte war meines Erachtens vor drei Jahren - darf eine nur für die SEs im Jahr 2020? ).
Vielen Dank,
Martin
PS: Der Grund, warum ich das so prominent mache, ist, dass ein Fertigungskunde mit mehr als 100 Lizenzen sich seit Jahren darüber aufregt, von JMP auf andere Lösungen, sogar Open Source, umzusteigen - und sie sind seit Jahren wirklich JMP-freundlich.
Betreff: Scripting: Aufwärtskompatibilität im AllgemeinenHallo Martin,
Nach meiner Erfahrung hängt die mangelnde Vorwärtskompatibilität fast immer damit zusammen, Dinge aus dem Bericht zu ziehen, um sie weiter zu manipulieren. Sie sagen, es ist vernünftig zu erwarten, dass sich Software auf natürliche Weise weiterentwickelt, aber wie es oder nicht, sind Änderungen in der Berichtsstruktur eine fast unvermeidbare Folge dieses Wunsches. Wir sollten uns immer bemühen, Kunden darauf hinzuweisen, die in der Tat viel von Skripten Gebrauch machen.
Wie Sie wissen, ist es für Software, die in der "Produktion" verwendet wird, sehr verbreitet, sogar erforderlich, Bereitstellungsbereiche zu haben, in denen aktualisierte Software gründlich getestet wird, bevor sie "live" geschaltet wird. Diese Disziplin könnte im Widerspruch zu der Tatsache stehen, dass JMP "nur" Desktop-Software ist, aber (wie Ihre Botschaft zeigt) die Risiken sind tatsächlich real und wir sollten den Benutzern helfen, JMP auf diese Weise zu sehen, wenn ihre Verwendungsmuster dies erfordern.
Kurz gesagt, diese Spannung ist ein Nebeneffekt der Tatsache, dass JMP so sehr funktional ist. Ich denke, wir können und sollten unsere Kunden besser auf die Risiken und Konsequenzen aufmerksam machen, die sich daraus ergeben, dass keine signifikante JSL-Codebasis auf der Grundlage guter industrieller Software-Engineering-Praktiken erstellt wird. F & E könnte Methoden bereitstellen, um alle erforderlichen Werte auf berichtsunabhängige Weise abzurufen. Dies steht jedoch nicht auf einer mir bekannten Roadmap und würde auf jeden Fall die Flexibilität beeinträchtigen, die JSL-Programmierer zu schätzen scheinen höchst.
Wie Sie wäre ich sehr daran interessiert, von anderen Beispielen zu hören, bei denen wir in Schwierigkeiten geraten sind. . .
Prost,
Ian
Betreff: Scripting: Aufwärtskompatibilität im AllgemeinenHallo Martin!
TL; DR:
Punkt 1: Codeumbrüche zwischen den Versionen sind normalerweise darauf zurückzuführen, dass die Benutzer JSL-Best Practices und -Skripts nicht defensiv anwenden. Punkt 2: Es liegt immer in der Verantwortung des Kunden, die Leistung der Software (von Haus aus oder auf andere Weise) zwischen den Versionen zu validieren. Sie sollten es wie jedes andere Fertigungswerkzeug behandeln, das vor der Freigabe für die Produktion überprüft wird.
Die lange Version:
Nur um den Kommentar zu kommentieren @ian_jmp made - Zum größten Teil sind Code-Brüche zwischen den Versionen darauf zurückzuführen, dass die Leute JSL-Best Practices nicht befolgen (oder nicht einhalten). Es ist viel einfacher, Code zu knacken, der funktioniert, aber nicht gut durchdacht ist. Mark Bailey nennt es "defensives Scripting". Ians Beispiel für Personen, die aus vorhandenen Berichten abrufen, ist ein klassisches Beispiel, insbesondere wenn sie den gesamten Anzeigebaum subskribieren. Die beste Vorgehensweise hierfür ist, einen Umrissfeldnamen als lokales Wahrzeichen zu verwenden und dann zu unterzeichnen (da sie sich nicht so oft ändern).
Ich habe auch einige Fälle erlebt, in denen Leute (ich selbst eingeschlossen) JSL bauen, das auf einer Funktion beruht, die zwischen den Versionen überarbeitet wird. Für mich haben die Änderungen in Recode, die in JMP 14 veröffentlicht wurden, einen Teil eines von mir verwalteten Add-Ins zerstört. In diesem Fall habe ich etwas getan, um den Code zum Laufen zu bringen, und wurde dafür verbrannt. Ein anderes (Kunden-) Beispiel ist, wenn jemand nicht ODBC-konforme Namen in seiner Datenbank verwendet hat. Als wir ODBC zwischen den Versionen erzwangen, brachen die Skripte. Hier hat jemand Standards nicht befolgt und sie wurden dafür verbrannt. Zum Mitnehmen ist es weniger wahrscheinlich, dass Ihre Kunden auf Probleme stoßen, wenn sie Code erstellen, der unseren Best Practices für das Schreiben von JSL entspricht. Wenn sie das tun, ist es ziemlich selten, dass JSL von Version zu Version wechselt. Die meisten Dinge, die ich mit dem Gedanken an defensives Scripting geschrieben habe, sind ziemlich robust - aber ich überprüfe immer noch, ob alles funktioniert. Normalerweise warte ich bis zu den letzten Veröffentlichungen der ersten Anwender, um sie zu testen (Änderungen an JMP sind zu diesem Zeitpunkt normalerweise ziemlich stabil).
Ian machte auch einen wirklich guten Punkt in Bezug auf das Wechseln zwischen Versionen. In den USA haben wir bestimmte Branchen, die stark reguliert sind (Pharma, Biotech, Finanzen und einige Fertigungsindustrien mit militärischen oder nationalen Sicherheitsanwendungen). Für diese Branchen gelten Validierungsanforderungen für jede neue Software oder neue Softwareversionen, für die die Benutzerbasis dokumentieren muss, dass sie die Funktion der Software überprüft hat, und dass zwischen den Versionen konsistente Ergebnisse erzielt werden. Meine anderen Kunden wissen, dass sie ihren Code zwischen den Versionen überprüfen müssen. Ich denke also, es ist wirklich das Problem der Reife und Disziplin in der Unternehmenskultur bei diesem Kunden (oder zumindest bei den Leuten, die dort die JSL generieren). Der von Ian erwähnte Test-Workflow (Staging, dann Freigabe für die Produktion) ist in allen Branchen, mit denen ich je gearbeitet habe (in den USA, in der EU oder in Asien), Standard - sie sollten es besser wissen als anzunehmen.
Fazit: Wenn Ihre JSL geschäftskritisch ist, müssen Sie sie wie jede andere Produktionssoftware behandeln und die JMP-Version (mit der geschäftskritischen JSL) validieren, bevor Sie sie für die Produktion freigeben. Ich wette, Ihre Beschwerden kommen hauptsächlich von Teilen der Ingenieurgemeinschaft, die nicht verstehen, wie das funktioniert. Sie könnten sie fragen, ob sie ein neues Gerät für die Produktion freigeben würden, bevor sie die Leistung des Werkzeugs gründlich testen und mit den anderen Teilen abgleichen - sie würden mit „Nein“ antworten. An diesem Punkt könnten Sie darauf hinweisen, dass Software ein Werkzeug ist und sein sollte gleich behandelt.
Follow-up-Gedanken
Mehr darüber nachdenken - wenn Leute JSL-Best Practices befolgen (mit Funktionen und Ausdrücken, Scoping, Namespaces, stark kommentiert ihren Code usw.) Es ist einfacher zu debuggen, wenn Dinge kaputt gehen (was sie auch tun). Es hört sich also so an, als ob der betreffende Kunde eine schlecht geformte, spröde JSL hat, die im Laufe der Zeit organisch gewachsen ist. Es ist wahrscheinlich schrecklich kommentiert und die Person, die es geschrieben hat, ist weitergezogen oder hat keine Ahnung, wie man es repariert (ich nenne diese Franken-Skripte) ... In diesem Fall würde ich empfehlen, dass sie jemanden, der mit JSL vertraut ist, zu den SAS Ed-JSL-Kursen schicken, um sich über bewährte Methoden zu informieren. Anschließend sollten sie den betreffenden Code modernisieren und einige SOPs einrichten, um die betreffende JSL hinzuzufügen zu ihren Software-Validierungstestplänen.
Betreff: Scripting: Aufwärtskompatibilität im AllgemeinenIch stimme allen bisherigen Kommentaren zu. Ich sehe die ganze Zeit 'Produktions'-Code, was schrecklich ist. Ich kann nicht glauben, dass es in der aktuellen Version funktioniert, geschweige denn, dass ich auf die Zukunft hoffe. Diese Benutzer haben nicht gelernt, JMP zu skripten. Das unterscheidet sich von der allgemeinen Computerprogrammierung. Es ist nicht nur Syntax. Sie hacken einfach. (Ich benutze den Begriff "Hacker" mit Verehrung. Diese Aktivität ist anders.) Sie wissen nicht, was sie tun.
In Bezug auf den Kommentar zu Änderungen in der JMP-Benutzeroberfläche, die den Zugriff auf die Berichtsebene verhindern, üben viele Benutzer kein sicheres Codieren. Es gibt Möglichkeiten, diese Probleme zu minimieren oder zu beseitigen, aber auf diese Weise wird spröder Code erzeugt.
Betreff: Scripting: Aufwärtskompatibilität im AllgemeinenVielen Dank für Ihre Kommentare. Ich stimme all Ihren Punkten in Bezug auf das Testen zu, bevor Sie in die Produktion gehen und das Speichern / Defensiv-Codieren (obwohl es den Benutzern wahrscheinlich nicht gefällt;)). Dies liegt definitiv in der Verantwortung des Benutzers und des Unternehmens, Skripte in welcher Sprache auch immer zu verwenden.
Ich möchte die Diskussion jedoch auch unter kritischeren Gesichtspunkten vorantreiben (- ich hoffe, dass wir am Ende allenfalls eine gemeinsame Botschaft an die Kunden und einen robusteren Automatisierungsprozess haben, um ihn an unsere Kunden zu verkaufen):
Ich komme aus einem Softwarehaus, das sich auf die Programmiersprache stützt, auf der das Tool basiert, und bin überrascht, wie oft ich erfahre, dass JSL von Version zu Version wechselt. In meinem früheren Leben gab es diese Probleme nur mit undokumentierten Funktionen und Features, nicht mit Einstellungen und Optionen wie z. B. Farbthemen und anderen Dingen in den Objektbäumen oder Methoden. Außerdem wurden alle Funktionen in vollem Umfang dokumentiert: Welche Ein- und Ausgänge stehen zur Verfügung, wie wird diese Option / Ein- / Ausgabe usw. beschrieben und definiert? Die Skriptanleitung und der Index sind beide nicht so. Dies ist eher der grundlegende Aufruf und alle anderen möglichen Optionen, die Sie selbst herausfinden müssen.
Man könnte sagen, dass alle nicht dokumentierten Teile Änderungen unterliegen - das wäre die einfache Antwort. Aber ich glaube es ist nicht so einfach. Die meiste Zeit müssen wir mindestens ein wenig von der "einen Ebene unter den eingebauten Funktionen" ändern. Wir stellen keine konkrete Dokumentation zur Verfügung, in der angegeben ist, dass "das ist, was Sie tun können" und "alles andere wird nicht unterstützt" (auch wenn dies jetzt funktioniert, Änderungen vorbehalten sind).
Eine Programmiersprache sollte ein solches Framework haben - oder wir sagen, JSL ist keine solche Programmiersprache und seien Sie bei unserer derzeitigen Befürwortung der Erstellung von Anwendungen vorsichtiger, um mehr Benutzer zu erreichen, da es einfach ist, reproduzierbaren Code zu erstellen, der jedoch möglicherweise nicht so zuverlässig ist für zukünftige Versionen.
Es wäre interessant zu hören, wie sich andere dazu fühlen (ich gebe zu, umso mehr und mit Absicht kritischer zu sehen, wieder eine abwechslungsreiche Diskussion über dieses Thema anzuregen), möge auch der eine oder andere Entwickler dies an seinem Tag tun Tagesbasis.
Betreff: Scripting: Aufwärtskompatibilität im AllgemeinenIhr letzter Punkt ist der kritische Punkt - JSL ist unglaublich leistungsfähig, aber im Grunde ist es keine „Programmiersprache“, sondern eine Skript- oder Makrosprache. Es verfügt über Strukturen, die der objektorientierten Programmierung ähneln, und kann in gewissem Maße auf diese Weise verwendet werden. Es basiert jedoch auf JMP und war immer darauf ausgelegt, Aufgaben in der GUI zu automatisieren oder die GUI zu erweitern. Viele Leute vergessen das - was auch bedeutet, dass sie vergessen, wenn Dinge im Produkt geändert werden -, dass Dinge in JSL kaputt gehen können (besonders wenn sie sie nicht gut codieren). Wir sollten nicht so über JSL reden wie über C ++ usw. Genau genommen sind sogar Python und R eng verwandte Programmiersprachen als JSL. Vielleicht sind einige Leute verwirrt, weil die Linie mit Excel-Makros und VBA verschwommen ist. Der Punkt ist jedoch, dass JSL eine Skriptsprache ist, die sich von einer Programmiersprache unterscheidet.
Beste,
M
Betreff: Scripting: Aufwärtskompatibilität im AllgemeinenHallo Mike,
Stimmen Sie zu, es ist eine Skriptsprache, und so sollte es getreten werden. Ich fand diese Diskussion wertvoll, da sie auch einige zusätzliche Aspekte hervorhebt, über die wir die Leute immer nachdenken sollten, wenn sie anfangen, ihre Prozesse zu automatisieren oder zu skripten. Haben wir - neben dem JMP-JSL-Schulungskurs - weitere JMP-relevante Referenzen für "defensives" Scripting?
Die meisten Referenzen im Web beziehen sich auf andere Sprachen und nicht auf JMP (obwohl Sie sie natürlich auch verwenden könnten). Die Mastering JMP-Webcasts decken keinen guten Programmier- / Skriptstil ab. Könnte ein interessantes Thema auch für eine Entdeckungspräsentation sein?
Betreff: Scripting: Aufwärtskompatibilität im AllgemeinenIch denke, das ist ein Bereich, in dem wir uns verbessern können. Es gibt viele Informationen über die Community, die Köpfe der Mitarbeiter, die Bücher und die Dokumentation, aber es gibt wirklich kein Dokument mit bewährten Methoden, das mir bekannt ist. Es sollte geben. Ich denke, ein Großteil der Bestürzung, die Sie auf dem Gebiet erleben, kann bis zu diesem einen Punkt gekreidet werden.
@ian_jmp - Vielleicht ist dies etwas, was die technische Community während des Anstoßes als Seitenleiste tun könnte.
Beste,
M
Betreff: Scripting: Aufwärtskompatibilität im AllgemeinenWie meine Antwort andeutete, denke ich, dass dies ein Bereich ist, in dem wir besser vorgehen können, zumal wir generell die Erstellung von Anwendungen als Bestandteil des Teils „Erweitern“ unserer „Land- und Erweiterungsstrategie“ fördern.
FWIW, meine persönliche Meinung ist, dass nicht jede SE JSL beherrschen sollte, es sei denn, sie neigen dazu. Aber ich glaube, dass jede SE wissen sollte, was möglich ist, und zusammen damit, wie eine gute Praxis aussehen könnte und welche Tücken es birgt, sich nicht daran zu halten.
Leider ist der Auftakt 2020 etwas komprimiert und die technische Strecke bereits organisiert. Wir werden also einen anderen Weg finden, damit umzugehen. Später mehr.
Betreff: Scripting: Aufwärtskompatibilität im AllgemeinenWir haben vor einigen Ausgaben damit begonnen, unseren Skriptkursen explizite "Best-Practice" -Vorschläge hinzuzufügen. Wir erweitern und verfeinern diese Vorschläge mit jeder Überarbeitung. Wir bekommen positives Feedback von Studenten. Naja, zumindest von den Studenten, die es nicht eilig haben, sich abzuhacken.
