Eine der größten Herausforderungen bei der Einführung von JMP in einem Unternehmen besteht darin, dass die Mitarbeiter JSL lernen und sich der JSL-Code im Unternehmen immer weiter verbreitet. Eine der größten Herausforderungen bei der Einführung von JMP in größerem Umfang in einem Unternehmen ist die Frage: Wie verwalten wir den gesamten benutzergenerierten Code? Wie kontrollieren wir all das?
Im Laufe der Jahre wurden hierfür viele verschiedene Methoden vorgeschlagen. Einige stammen aus der Informatik und Softwareentwicklung, beispielsweise Versionskontrollsysteme. Andere schlagen vor, einfach irgendwo ein freigegebenes Laufwerk zu verwenden. Es stellt sich heraus, dass beide Methoden ihre Vor- und Nachteile haben.
Um Ihnen ein wenig Licht am Ende des Tunnels zu geben: Es gibt hier tatsächlich einen Mittelweg, der für dieses Problem ganz gut funktioniert, nicht ganz ... Ich möchte nicht alle Ressourcen darauf verwenden, ein vollwertiges Softwareentwicklungsunternehmen im eigenen Haus aufzubauen, das sich um den Softwareverwaltungsteil kümmert. Ich möchte nicht den Wilden Westen betreiben, der nur ein freigegebenes Laufwerk auf dem Server von jemandem ist.
Es stellt sich jedoch heraus, dass diese beiden Extreme ihre Vor- und Nachteile haben. Wenn es um Git oder Versionskontrollsysteme geht, ist GitHub normalerweise das System, mit dem sich die Leute am besten auskennen. Codebasen verwalten? Genau das kann es wirklich gut. Es ist gutes Zeug.
Einfaches Bereitstellen von Updates? Das ist nicht seine Stärke. Dafür ist es nicht konzipiert. Es ist für den professionellen Softwareentwicklungs-Workflow konzipiert, und darum geht es hier nicht. Das macht es nicht besonders gut.
Die Kontrolle von Zugriffs- und Versionsberechtigungen funktioniert natürlich recht gut. Die Versionskontrolle zu behalten und zu wissen, wie Änderungen im Laufe der Zeit verfolgt werden, all das ist genau das, wofür Versionskontrollsysteme konzipiert sind. Aus diesem Grund ist es nicht anfängerfreundlich. Es ist für Profis konzipiert.
Ich habe Beispiele für den Einsatz in der Praxis gesehen, aber in der Regel handelt es sich dabei um Organisationen, die über die nötigen Mitarbeiter, Ressourcen und Zeit verfügen, um eine eigene Softwareentwicklungsgruppe im Unternehmen einzurichten. Das mag in bestimmten Situationen funktionieren, oder es gibt sie vielleicht schon aus anderen Gründen.
Das andere Extrem ist die Idee, nur JSL-Dateien und einen freigegebenen Ordner, ein freigegebenes Verzeichnis auf einem Server zu verwenden. Das ist fast das Spiegelbild der Probleme des Versionskontrollsystems. Die Verwaltung der Codebasis ist nicht besonders gut. Mit einigen dieser Cloud-Systeme wird es zwar besser, aber es ist immer noch nicht optimal.
Updates einfach bereitstellen? Sicher. Klicken Sie einfach auf das neueste Update. Vielleicht versenden Sie eine E-Mail oder nutzen Add-Ins. Code, der im Laufe der Zeit für diesen speziellen Workflow vorgeschlagen wurde, können Sie in Ihre Add-Ins integrieren. Definitiv eine Möglichkeit, aber nicht trivial. In dieser Hinsicht besser als das Versionskontrollsystem.
Zugriffskontrolle? Ehrlich gesagt nicht so toll. Anfängerfreundlich? Ja. Nicht schlecht, aber auch nicht überragend. Es gibt einen Mittelweg. Mein Kollege, mein Co-Autor und ich sind tatsächlich aus zwei unterschiedlichen Entwicklungsaktivitäten darauf gekommen. Wir sind beide mehr oder weniger auf die gleiche Lösung gekommen. Es war interessant zu sehen, wie wir uns bei dieser Idee in der Mitte getroffen haben.
Die Idee dahinter ist, ob Sie es glauben oder nicht, OneDrive. Jeder hat es. Es ist ein Unternehmenssystem. Nun ja, nicht jeder, aber ein Großteil der Unternehmen hat Zugriff auf OneDrive oder ein gleichwertiges System. Ich werde für diese Sitzung OneDrive verwenden, weil ich es habe, aber es gibt auch gleichwertige Systeme.
Die Vorteile sind jedoch wirklich überraschend. Die Verwaltung der Codebasis ähnelt JSL, bietet jedoch mehr Versionskontrolle bzw. Bearbeitungsrechte und kann den Verlauf verfolgen und zu früheren Codeversionen zurückkehren. Wenn etwas schiefgeht, der Code beschädigt ist oder Ähnliches, können wir ihn zurücksetzen. Diese Möglichkeiten bieten uns die Unternehmenssysteme, über die wir hier sprechen.
Einfache Bereitstellung von Updates. Hier zeigt sich, wie wichtig diese Lösung ist. Wir können eine mehr oder weniger automatisierte Update-Strategie für ein ganzes Unternehmen einrichten. Praktisch ohne einen Finger rühren zu müssen. Es ist nahezu ohne Code. Wir müssen nur ein paar Code-Schnipsel in unsere Add-Ins einfügen, aber darüber hinaus funktioniert alles per Mausklick. Mit diesen Systemen ist das unglaublich einfach.
Kontroll- und Bearbeitungsberechtigungen. Auch diese sind mit den Mauern verbunden. Sie können Benutzern die Berechtigung zum Anzeigen, Bearbeiten, Herunterladen oder Herunterladen erteilen. Sie können Benutzern bei Bedarf Vollzugriff gewähren und diesen bei Bedarf ein- und ausschalten. Sie können dies für Gruppen tun. Es gibt Richtlinienoptionen und ähnliches.
Es verfügt tatsächlich über ein sehr gutes Zugriffsberechtigungssystem und ist anfängerfreundlich. Wie bereits erwähnt, ist nur sehr wenig zusätzliche Programmierung erforderlich. Wenn Sie bereits Add-Ins schreiben, wissen Sie alles, was Sie dafür wissen müssen. Die Implementierung ist kinderleicht.
Was ist der Trick? Der Trick liegt darin, dass JMP ein Add-In installiert. Dieses besteht im Grunde nur aus einem Ordner mit JSL-Dateien, einigen speziellen Dateien, die JMP mitteilen, wo es in der GUI abgelegt werden soll, und einigen Metadaten zum Add-In. Meistens handelt es sich jedoch nur um einen Ordner mit JSL-Dateien, den JMP an einem bestimmten, bekannten Ort ablegt.
Interessant ist jedoch, dass die wichtigen Dateien für das Add-In überall dort gespeichert werden können, wo JMP darauf zugreift. Sie müssen nicht in diesem Ordner liegen. Sie können sie überall ablegen. Hyde und ich kamen zu der Erkenntnis: Was hindert uns daran, die wichtigen Dateien in einem OneDrive-Ordner abzulegen und dann einfach einen Zeiger vom Add-In zu diesen wichtigen Dateien zu verwenden und sie dort zu öffnen?
Es stellt sich heraus, dass nichts dagegen spricht. Nichts hindert Sie daran. Das ist das Ergebnis. Einige der nächsten und die übernächste Folie dienen später eher als Referenz, aber wir gehen sie nur kurz durch, damit wir einen kurzen Überblick darüber haben, was hier passiert.
Im OneDrive in der Cloud, im OneDrive-Ordner, befindet sich das Hauptelement des Add-Ins. Wir werden die Benutzeroberfläche und den Add-In-Code haben. So hatte Hyde es sich vorgestellt. Ich hatte die Idee, Ressourcen, große Bibliotheken mit Materialien, die viel Speicherplatz auf der Festplatte beanspruchen, bereitzustellen und diese nur dann zu öffnen, wenn man sie öffnen möchte. Ansonsten möchte man den Speicherplatz auf der Festplatte nicht belegen. All diese Materialien können im OneDrive-Ordner gespeichert werden und bleiben dort.
Auf dem JMP-Desktop befindet sich ein winziges Skript, vielleicht 20 Zeilen lang. Es dient hauptsächlich dazu, es für den Benutzer lesbar zu machen. Es erfüllt drei Aufgaben. Drei konkrete Aufgaben. Erstens prüft es, ob es weiß, wo die Add-In-Dateien gespeichert sind. Gibt es einen Speicherort? Wenn nicht, muss es einen Dialog anzeigen, der fragt: „Hey, wo soll ich nach dem Add-In suchen?“ Anschließend muss das Add-In-Paket geöffnet werden. Das ist alles, was es tut. Diese drei Aufgaben.
Auf Ihrer Benutzerfestplatte befindet sich außerdem ein sogenannter Spiegel des OneDrive-Speicherorts. Dieser Spiegel enthält, je nach Einrichtung, entweder nur logische Verknüpfungen, Links zu Dateien (Aliase, falls Sie diese kennen) oder Kopien der synchronisierten Dateien. Beide Methoden haben Vor- und Nachteile, funktionieren aber gleichermaßen gut.
Option eins: Sie verwenden nur logische Verknüpfungen. Der Vorteil: Die Dateigröße ist sehr gering. Es entsteht ein Platzbedarf auf der Festplatte. Es handelt sich lediglich um Links, und die Dateien werden zur Laufzeit abgerufen. Sie erhalten aktuelle, genaue Dateiinformationen. Der Nachteil: Es funktioniert nicht ohne Internetverbindung. Wenn Sie beispielsweise im Flugzeug sitzen und keinen WLAN-Zugang haben, werden Ihre Add-Ins möglicherweise gar nicht geladen.
Ein weiterer Nachteil ist, dass es je nach Größe des Add-Ins zu einer kleinen Verzögerung zwischen dem Klicken auf den Link in JMP und dem Öffnen des Add-Ins kommen kann. Beides sind Nachteile. Ich würde das nicht unbedingt als Nachteil bezeichnen, aber bei größeren Add-Ins kann es zu einer leichten Verzögerung kommen.
Option zwei, die ich Ihnen heute zeigen werde, ist die Ordnersynchronisierung. Diese Option benötigt zwar mehr Speicherplatz auf der Festplatte, ermöglicht aber den Offline-Zugriff und das Laden erfolgt – zwar nicht sofort, aber deutlich schneller. Wenn eine neuere Version einer Datei geladen werden muss und diese noch nicht synchronisiert ist, kann es zu einer kleinen Verzögerung kommen. Der Vorteil dabei ist jedoch, dass hier geänderte Dateien automatisch in Ihren lokalen Ordner kopiert werden.
In beiden Fällen bleiben die Lese-/Schreibberechtigungen der Versionskontrolle bestehen. Nimmt jemand eine Änderung auf seiner lokalen Festplatte vor, wird eine Kopie der Datei erstellt. Das Original kann nicht geändert werden, und es wird nur auf das Original verwiesen. Wenn jemand etwas verändert und dabei einen Fehler macht, wird beim nächsten Laden des Add-Ins das Original geladen. Die Änderung wird nicht geladen. Wir haben diese Versionskontrolle, diesen geschützten Workflow, in jedem Fall.
Das Einrichten des OneDrive-Speicherorts ist auf verschiedene Arten möglich. Die einfachste Möglichkeit ist meiner Meinung nach Teams. Dort beginnen wir heute mit der Demo. Wenn Sie in Teams ein Team einrichten, wird automatisch die benötigte SharePoint-Site erstellt. Anschließend können Sie von dort aus einen Ordner hinzufügen und die Synchronisierung einrichten.
Anschließend können Sie die SharePoint-Site aufrufen. Genau das tun Ihre Benutzer. Sie rufen die SharePoint-Site direkt auf und richten dort die Synchronisierung ein. Dort können Sie ihnen Berechtigungen zum Anzeigen, Bearbeiten, Herunterladen usw. erteilen. Dort können Sie ihnen auch Zugriffsrechte auf die Inhalte erteilen. Sie haben auch Zugriffskontrolle für das Add-In. Praktisch. Schauen wir uns kurz an, wie das geht.
Das ist Teams. Ich habe die Teams-Funktion. Ich bin hier in meiner Teams-Gruppe. Dort öffnet sich normalerweise ein Button, der angezeigt wird. Ich habe ihn gerade klein. Dort steht „Neues Team erstellen“. Man erstellt ein neues Team und den Kanal. Wenn man dann in den Kanal geht, gibt es darunter die Option „Dateien“.
Sie können eine neue Datei oder einen neuen Ordner erstellen. Normalerweise erstelle ich einen neuen Ordner und nenne ihn „Add-In-Inhalt“. Von hier aus kann ich die kleinen Punkte verwenden und habe Optionen zum Herunterladen oder zur Synchronisierung mit SharePoint. Ich öffne mein SharePoint-Laufwerk. Dies ist mein SharePoint-Laufwerk. Es ist derselbe Speicherort. Ich befinde mich in diesem Ordner. Dies ist der Inhalt des Add-Ins. Das ist der Kern meines Add-Ins, den ich Ihnen zeigen werde.
Unter diesen drei Punkten hier gibt es eine Option mit der Bezeichnung „Synchronisieren“. Das bewirkt in meinem Dateisystem … Unter Windows sieht es etwas anders aus, aber auf dem Mac erstellt es in meinem Dateisystem einen Speicherort für gemeinsam genutzte Bibliotheken und erstellt eine Kopie des Ordners hier.
Wenn ich nun Änderungen an diesem Ordner vornehme, weil ich über Bearbeitungsberechtigungen verfüge, erhält jeder andere, der Zugriff darauf hat, automatisch Kopien dieser Änderungen. Die Änderungen werden an die SharePoint-Site weitergeleitet und dann an alle anderen weitergegeben. Hier beginne ich mit der Bearbeitung.
Schauen wir uns die Datei jetzt kurz an. Diese ist nicht wirklich wichtig. Es geht nur um den Inhalt. Aber schauen wir uns mal an, wie so eine Datei aussieht. Das ist das Add-In selbst, das ich erstellt habe. Ich werde Sie durch die Erstellung des Add-Ins selbst führen, da ich dafür nur den Add-In-Assistenten verwende.
Schauen wir uns an, was wir hier haben. Das sind die Teile, die uns nicht so wichtig sind. Das sind die Dinge, die JMP wissen muss. Der Add-In-Launcher und die Add-In-Einstellungen sind die beiden, die uns interessieren. Die Add-In-Einstellungen enthalten einen Ordner oder eine Datei. Ich füge sie hier unmarkiert ein, da sie beim Testen neulich gelöscht wurde.
So sollte es standardmäßig aussehen. Das Shell-Skript fragt mich: „Hey, wo ist der Add-In-Inhalt für dieses Add-In?“ Sobald es das weiß, schreibt es es in das Einstellungsskript zurück, sodass ich nicht bei jedem Ausführen des Add-Ins gefragt werden muss. Es fragt mich nur einmal und merkt sich die Information.
Schauen wir uns dieses Shell-Skript ganz schnell an. Wir wollen den Blog erstmal weglassen. Es gibt drei, wieder sehr kurze Code-Schnipsel. Viel zu sehen gibt es hier nicht. Es gibt einen Dialog, der fragt, wo das JSL für dieses Add-In wirklich liegt. Versuche, die Einstellungen zu öffnen. Dann gibt es hier eine Schleife, die entweder versucht, den Code zu öffnen oder mich fragt, wo er ist. Das ist alles, was wir hier sehen.
Ich habe dieses Add-In erstellt und in meinem Add-In-Ordner abgelegt. Wenn ich hier oben in JMP „Demo“ wähle, erscheint die Meldung: „Hey …“ Sie können es hier unten nicht sehen, aber es heißt: „Bitte wählen Sie Ihr Verzeichnis für den Trainingsstarter.“ Nun ja, für dieses Add-In. Ich habe vergessen, den Text zu ändern. Ich gehe einfach hinein und sage: „Hier ist mein freigegebenes Laufwerk, und hier befindet sich mein Ordner.“ Ich sage: „Okay, öffnen“. Das Add-In wurde vom OneDrive-Speicherort aus gestartet.
Ich kann hier zurückgehen, das Add-In wieder öffnen und einen anderen Text für die Add-In-Datei erhalten. Ich habe das Add-In hinzugefügt und führe es erneut aus. Der neue Text wird unten angezeigt. Um Ihnen einen Eindruck von der Komplexität zu vermitteln, möchte ich Ihnen zwei verschiedene Add-Ins kurz vorstellen, die beide dies nutzen. Ich werde nicht auf alle Details eingehen. Lassen Sie mich das abschließen. Das ist, was ich will.
Das erste ist das von mir erstellte Programm namens JMP on the Spot. Es nutzt das Konzept, das wir heute besprechen, um Inhalte für einen Webbrowser oder ein ähnliches Viewer-Tool abzurufen. Repository oder Bibliothek wäre wohl eine bessere Beschreibung. Wenn wir JMP on the Spot aufrufen, sind alle Inhalte hier ausschließlich in der Cloud vorhanden. Wenn ich es öffne, werden sie in Echtzeit heruntergeladen.
Eine weitere Option ist die, die wir als SEs verwenden, um unsere Materialien zu verwalten, wenn wir eine neue Version lernen, was für JMP 19 besonders geeignet ist. Aber hier werden unsere Materialien gespeichert. Es verwendet genau dieses Add-In. Diese GUI und alles, was damit zusammenhängt, befindet sich auf einem OneDrive-Speicherort.
Wenn wir es uns ansehen würden, würde ich es hier sehen. Das Add-In auf meiner Festplatte enthält lediglich die Einstellungsdatei, die wir bereits gesehen haben, und zwar genau die Datei, die ich Ihnen für das Demobeispiel gezeigt habe. Alles andere geschieht in Echtzeit. Ich habe es auf meine Festplatte heruntergeladen, während es vom Team bearbeitet wird.
Sobald unsere Materialien für JMP 19 und JMP 18 hochgeladen sind, werden sie auf OneDrive hochgeladen und automatisch auf meinen Rechner übertragen. Ich muss mich nicht um die Aktualisierung meiner Add-Ins, Videos und anderer Inhalte kümmern, auch nicht um die wirklich umfangreichen Inhalte, die wir manchmal für Schulungen benötigen. Diese befinden sich in der Cloud, ich lade sie nicht herunter. Das ist auch nicht nötig. Ich belege dafür keinen Speicherplatz auf meiner Festplatte.
Was haben wir heute gesehen? Wir haben gesehen, dass OneDrive uns die Möglichkeit bietet, die Codebasis zu verwalten, Updates einfach bereitzustellen, Zugriff und Berechtigungen zu steuern und anfängerfreundlich ist. Es ist nur sehr wenig zusätzliche Programmierung erforderlich, außer dass Sie Ihr eigenes JSL schreiben. Sie wissen bereits alles, was Sie dafür wissen müssen. Sie müssen sich lediglich einen kleinen Trick merken: Es gibt keine Regel, die besagt, dass das Add-In im Add-In-Repository gespeichert sein muss.
