組織内でJMPの導入を開始する際に直面する最大の課題の一つは、ユーザーがJSLの使い方を学び始め、組織内でJSLコードが急増し始めることです。JMPが企業内で大規模に導入されるにつれて、最大の課題の一つは、ユーザーが生成したコードを大規模に管理する方法、つまり、これらすべてをどのように制御するかという問題になります。
長年にわたり、これを実現するための様々な方法が提案されてきました。コンピュータサイエンスやソフトウェア開発分野から生まれたものや、バージョン管理システムを使うものなどもあります。また、共有ドライブを使うという提案もあります。しかし、どちらにも長所と短所があることがわかりました。
トンネルの出口に少しでも光明があるとすれば、実はこの状況にうまく対応できる中間地点があるということです。…ソフトウェア管理を担当する社内に本格的なソフトウェア開発会社を設立するために、すべてのリソースを投入するつもりはありません。誰かのサーバー上の共有ドライブだけで、ワイルド・ワイルド・ウェストを運営するような、そんな無法地帯を運営するわけではありません。
しかし、この両極端にはそれぞれ長所と短所があることがわかりました。Gitやバージョン管理システムについて話すとき、GitHubは一般的に最もよく知られています。コードベースの管理？まさにそれがGitHubの得意とするところです。本当に素晴らしいものです。
アップデートを簡単に展開できる？それは得意分野ではありません。そもそも、そのために設計されたものではありません。プロフェッショナルなソフトウェア開発ワークフロー向けに設計されており、ここで話題にしているのはそれではありません。特にその点では優れています。
アクセスとバージョン権限の制御は、もちろん非常にうまく機能します。バージョン管理を維持し、変更が時間の経過とともにどのように追跡されるかを把握することは、まさにバージョン管理システムが設計されている目的です。そのため、初心者向けではありません。プロフェッショナル向けに設計されています。
実際に使用されている例を見たことがありますが、それらは通常、社内に専任のソフトウェア開発グループを立ち上げるための人材、リソース、そして時間を持つ組織です。特定の状況ではうまくいくかもしれませんが、他の理由で既にそのようなグループがある場合もあります。
もう一方の極端な例として、JSLファイルと共有フォルダ、つまりサーバー上の共有ディレクトリだけを使うというアイデアがあります。これはバージョン管理システムの問題とほぼ同じです。コードベースの管理は、あまり良くありません。クラウドシステムの一部では改善されつつありますが、それでもまだ良くありません。
アップデートを簡単に展開できますか？もちろんです。最新のアップデートをクリックするだけです。メールを送信したり、アドインを使ったりすることもできます。この特定のワークフローを支援するために長年にわたり提案されてきたコードをアドインに追加することもできます。もちろん可能ですが、簡単ではありません。この点ではバージョン管理システムよりも優れています。
アクセス制御？正直に言うと、あまり良くないですね。初心者向け？ええ。悪くはないですが、最高とも言えません。実は、これには中間点があるようです。同僚と私、共著者と私は、実はそれぞれ異なる開発活動からこの問題に取り組んでいました。そして、ほぼ同じ解決策にたどり着きました。このアイデアに関して、私たちがどのようにして中間点で合意に至ったのか、興味深い点でした。
信じられないかもしれませんが、実はそのアイデアとはOneDriveなんです。誰もが使っているエンタープライズシステムです。まあ、全員ではないかもしれませんが、かなりの数の組織がOneDriveかそれに相当するものを利用していると言っておきましょう。このセッションでは、私が持っているのはOneDriveだけなのでOneDriveを使います。ただし、同等のものは他にもあります。
しかし、そのメリットは本当に驚くべきものです。コードベースの管理はJSLと似ていますが、バージョン管理や編集コントロールが強化され、履歴を追跡して以前のバージョンのコードにロールバックする機能も備わっています。何か問題が発生した場合、コードに破損などがあった場合、ロールバックできます。ここで取り上げているエンタープライズシステムを使用することで、こうした機能を実現できるのです。
アップデートを簡単に展開できます。これがこのソリューションの真髄です。企業全体を対象に、ほぼ自動化されたアップデート戦略を構築できます。現実的に言えば、指一本動かす必要もありません。ほぼコードレスです。アドインに少しコードを記述する必要がありますが、それ以外はすべてポイントアンドクリックで操作できます。これらのシステムを使えば、驚くほど簡単に実行できます。
制御と編集権限。繰り返しになりますが、これらもこのツールに付属しています。ユーザーに表示、編集、ダウンロードの権限を与えることができます。必要に応じてフルアクセスを許可したり、必要に応じてオン/オフにしたりできます。グループ単位で設定することも可能です。ポリシーオプションなども用意されています。
実のところ、非常に優れたアクセス権限システムを備えており、初心者にも使いやすいです。先ほども申し上げたように、追加のコーディングはほとんど必要ありません。既にアドインを作成されている方であれば、必要な知識はすべてご存知でしょう。実装も非常に簡単です。
コツは何でしょうか？実は、JMPがアドインをインストールすると、そのアドインは基本的にJSLファイルと、GUI上の配置場所をJMPに指示するための特別なファイル、そしてアドインに関するメタデータが入ったフォルダに過ぎないのです。しかし、実際にはJMPはJSLファイルを取得し、JMPが認識している特定の場所に配置するだけのフォルダなのです。
しかし興味深いのは、アドインにとって重要なファイルはJMPがアクセスできる場所であればどこにでも置けるということです。必ずしもそのフォルダに置く必要はありません。好きな場所に配置できます。Hydeと私が気づいたのは、重要なファイルをOneDriveフォルダに置き、アドインからその重要なファイルへのポインタでOneDriveフォルダ上で開くという方法に、一体何が妨げになっているのかということです。
結局、何も問題はありません。これを実行することを妨げるものは何もありません。これを実行すると、最終的にこうなります。次のスライドと次のスライドは、後で参照するためのものですが、ここで何が起こっているのかを少し説明するために、簡単に見ていきましょう。
クラウド上のOneDrive、OneDriveフォルダにアドインの核となる部分を配置します。ユーザーインターフェースとアドインのコードを配置します。Hydeはそう考えていました。私は、リソース、つまりハードドライブの容量を大量に消費するような素材の大規模なライブラリを配置し、実際に開くときにだけ取り出すというアイデアから着想を得ました。そうでなければ、ハードドライブの容量を消費したくないはずです。こうしたものはすべてOneDriveフォルダに配置でき、そこに保存されます。
JMPのデスクトップには、20行ほどの小さなスクリプトがあります。大部分はユーザーが読みやすいようにするためのものです。このスクリプトは3つのことを行います。具体的には3つのことです。1つ目は、アドインファイルがどこに保存されているかを確認します。保存場所が分かっているか確認します。もし保存場所が分かっていなければ、「アドインはどこで探せばいいですか？」と尋ねるダイアログを表示します。そして、アドインパッケージを開きます。これがJMPのやっていることの全てです。この3つのことです。
ユーザーのハードドライブに存在するもう一つのものは、OneDriveのミラーと呼んでいるものです。このミラーは、設定方法によって、論理的なリンク、ファイルへのリンク、エイリアス（ご存知であれば）のみ、あるいは同期された実際のファイルのコピーのいずれかになります。どちらの方法にも長所と短所があり、どちらも同じように機能します。
オプション1は、論理リンクのみを使用する方法です。メリットはファイルサイズが非常に小さいことです。ハードドライブへの負荷も小さく、リンクのみで構成され、実行時にファイルを読み込みます。最新の正確なファイル情報が得られます。デメリットは、インターネットに接続していないと動作しないことです。飛行機に乗っているときなど、Wi-Fiにアクセスできない場合は、アドインが全く読み込まれない可能性があります。
もう一つの欠点は、アドインのサイズによっては、JMP内のリンクをクリックしてからアドインが開くまでに多少の遅延が発生する可能性があることです。どちらも欠点と言えるでしょう。ただし、大きなアドインの場合は多少の遅延が発生する可能性があることをご理解いただければ幸いです。
2つ目の方法は、今日ご紹介する方法ですが、同期フォルダオプションです。このオプションはハードドライブの容量を多く消費しますが、オフラインアクセスが可能で、読み込みは瞬時ではありませんが、間違いなく高速です。ファイルの新しいバージョンを取得する必要があり、まだ同期されていない場合は、多少の遅延が発生する可能性があります。しかし、このオプションの利点は、ここでファイルが変更されると、自動的にローカルフォルダにコピーされることです。
どちらの場合でも、読み取り/書き込みバージョン管理権限は有効です。誰かがローカルハードドライブに変更を加えると、ファイルのコピーが作成されます。元のファイルに変更を加えることはできず、元のファイルへの参照のみとなります。誰かがファイルをいじってミスを犯した場合、次にアドインを読み込む際には元のファイルが読み込まれます。変更内容は読み込まれません。私たちは、どんな状況でもバージョン管理と保護されたワークフローを常に維持しています。
OneDriveの場所を設定するには、いくつかの方法があります。私が見つけた最も簡単な方法はTeamsを使うことです。今日のセッションのデモ部分はTeamsから始めます。Teamsでチームを設定すると、必要なSharePointサイトが自動的に作成されます。その後、Teamsからそのサイトにフォルダーを追加し、同期を設定することもできます。
必要に応じて、SharePointサイトにアクセスすることもできます。ユーザーはSharePointサイトに直接アクセスし、そこで同期を設定します。そこで、ユーザーに表示、編集、ダウンロードなどの権限を付与できます。コンテンツへの権限を付与できるだけでなく、アドインへのアクセス制御も行えます。とても便利ですね。では、実際にどのように行うのか、簡単に見ていきましょう。
これはTeamsです。私はTeamsを使っています。実はここにTeamsグループに参加しています。Teamsグループに入ると、通常はボタンが表示されます。今は小さなボタンが表示されています。「新しいチームを作成」というボタンです。新しいチームを作成し、チャンネルを作成します。チャンネルを開くと、チャンネルの下に「ファイル」というオプションがあります。
新しいファイルやフォルダーを作成できます。私は通常、新しいフォルダーを作成し、「アドイン コンテンツ」という名前を付けます。ここから小さなドットを使って、ダウンロードするか、SharePoint と同期するかを選択できます。SharePoint ドライブを開きます。これは SharePoint ドライブです。同じ場所です。実際には、このフォルダーの中にいます。これがアドインのコンテンツです。これが、これからご紹介するアドインの核となる部分です。
ここにある3つのドットの下に「同期」というオプションがあります。これはファイルシステム上で何をするのでしょうか…Windowsでは少し見た目が異なりますが、Macではファイルシステム上で共有ライブラリの場所を作成し、ここにあるフォルダのコピーを作成します。
さて、このフォルダに変更を加えると、編集権限を持っているので、このファイルに変更を加えると、このフォルダにアクセスできる他のユーザーにも自動的に変更内容のコピーがプッシュされます。そして、SharePointサイトにプッシュされ、他のユーザーにも送信されます。ここから編集作業が始まります。
では、ファイルの内容を簡単に見てみましょう。これはそれほど重要ではありません。コンテンツだけです。しかし、このファイルの一つがどのようなものか見てみましょう。これは私が作成したアドインそのものです。これから手順を説明します。アドインウィザードを使用するだけなので、アドイン自体の作成方法については説明しません。
ここに何があるか見てみましょう。これらはあまり気にしない部分です。JMPが認識する必要があるものです。重要なのはアドインランチャーとアドイン設定の2つです。アドイン設定にはフォルダまたはファイルがあります。先日テストした際に削除してしまったので、ここでは選択せずにそのままにしておきます。
デフォルトではこのように表示されます。このシェルスクリプトでは、プロンプトが表示され、「このアドインのアドインコンテンツはどこにありますか？」と尋ねられます。それを認識すると、この設定スクリプトに書き戻されます。そのため、アドインを実行するたびに尋ねられる必要はありません。一度尋ねれば、それを記憶します。
早速このシェルスクリプトを見てみましょう。ブログは割愛します。3つの非常に短いコードがあります。特に注目すべき点はありません。このアドインのJSLが実際にどこにあるかを尋ねるダイアログがあります。設定を開いてみてください。そして、コードを開こうとするか、どこにあるのかを尋ねるループがあります。ここで確認しているのはこれだけです。
このアドインを作成して、アドインフォルダに配置しました。JMPを開いて「デモ」と入力すると、下の方では見えませんが、「トレーニングスターターのディレクトリを選択してください」というメッセージが表示されます。このアドインの場合、このテキストを変更するのを忘れていました。共有ドライブとフォルダの場所を指定して、「開く」をクリックするだけです。アドインはOneDriveから起動されます。
できることは、ここに戻ってこれを開くと、このアドインファイルに別のテキストが追加されていることです。ファイルを開いて、アドイン自体を追加しました。もう一度アドインを実行すると、新しいテキストが下部に表示されます。これがどれほど複雑になるかご理解いただけるように、このアドインを活用している2つのアドインを簡単に紹介したいと思います。それぞれのアドインの詳細についてはここでは説明しません。さて、これで終わりにしましょう。これが私のやりたいことです。
一つ目は、私が作成した「JMP on the Spot」です。これは、今日お話ししているコンセプトを使って、Webブラウザやビューアのようなアプリケーションにコンテンツを取得するものです。リポジトリやライブラリといった表現の方が適切かもしれません。JMP on the Spotを起動すると、そこに保存されているコンテンツはすべてクラウド上にのみ存在します。開きたいと思ったら、リアルタイムでダウンロードされます。
もう一つの選択肢は、SEとして新しいリリースを学習する際に資料を管理するために使用するもので、JMP 19に非常に適しています。資料はここに保存されています。まさにこのアドインを使用しています。このGUIとこれに関連するすべてのものは、OneDriveに保存されています。
実際に確認してみましょう。ここにあります。ハードドライブ上のアドインの中に実際に存在するのは、先ほどご覧いただいた設定ファイルと、デモのサンプルでご紹介したファイルだけです。それ以外はすべてリアルタイムです。チームが編集中のファイルをハードドライブにダウンロードしました。
JMP 19とJMP 18の資料がアップロードされると、OneDriveにアップロードされ、自動的に私のマシンに取り込まれます。アドインやビデオ、トレーニングで使う大容量コンテンツの更新を気にする必要がありません。これらはクラウドに保存されているので、ダウンロードする必要はありません。ダウンロードする必要もありません。ハードドライブの容量を消費することもありません。
今日は何を見ましたか？OneDriveはコードベースを管理し、更新プログラムを簡単に展開し、アクセスと権限を制御し、初心者にも使いやすく、独自のJSLを作成する場合を除いて追加のコーディングはほとんど必要ありません。必要な知識はすべて既に身についています。必要なのは、アドインがアドインリポジトリに必ず保存されなければならないというルールがないという、ちょっとしたコツを覚えておくことだけです。
