こんにちは。Eric Hillです。JMPのJMP Live開発チームのマネージャーを務めています。これからJMP Live 19の新機能をいくつかご紹介します。皆さんが視聴されているのはそのためです。まずは管理図から始めましょう。こちらがJMPから取得した洗濯機のサンプルデータです。P管理図を実行してみましょう。
ここに管理外の点がいくつかあるのがわかりますね。これをJMP Liveに公開します。「レポートをJMP Liveに公開」。これが正しいレポートです。新しいレポートを公開します。保存場所を探す必要があるので、管理図トリアージスペースまたはフォルダに保存します。タイトルは良さそうです。新しいデータを公開します。データはまだJMP Liveには公開されていません。さあ、これで完了です。
JMP Liveの以前のバージョンでは、管理図を公開すると、管理図を見ることができるほぼすべての人に通知が送られていました。警告が出ている管理図を公開すると、通知が送られ、そのことが起きたことを皆が認識し、確認できるようにしていました。
しかし、その後は、できることがほとんどなくなってしまいました。オフにすることもできず、「もう大丈夫、もう管理できる」と言い訳することもできませんでした。もうこの話はやめてください。これで話は終わりです。JMP Live 19では、このプロセス全体を徹底的に刷新し、管理図の警告を確認するだけでなく、管理、対処、そしてJMP Live内で解決まですべて行えるようにしました。
それを示すためにできることの一つは、管理外の点の一つをポイントしてクリックすることです。すると左側にパネルが表示され、その点に関する詳細情報が表示されます。不良率、どの列にあるか、どのテストに不合格になったかなどです。この点は3シグマテストの1点目に失敗しました。
この管理図を見た他の人が何が起こっているのか理解できるように、情報を追加できる箇所がいくつかあります。しかし、私ができる最も重要なことは、この管理図を調査し、原因や解決策を解明し、それをここに文書化する役割を担うと思われる人にこの管理図を委任することです。
このプロセスはChang Huaが担当していることは承知しています。彼女は、この管理図の警告を調査し、何が起こっているのかを解明するのに最適な人物だと思います。この変更を保存します。変更はこれだけです。さて、ここにChang Huaがログインしている別のブラウザがあります。これが彼女のセッションです。
通知の一覧を見ると、現在アクティブな通知があるのが分かります。それをクリックすると、Eric Hill氏によって管理図の警告が割り当てられたことが分かります。彼女はその警告か通知をクリックするだけで、管理図の警告を割り当てた場所に戻ることができます。これで、彼女は調査プロセスを開始できます。
彼女がまず最初にやるべきことは、自分がこの件を担当していることを周囲に知らせることです。この件を「公開」から「調査中」に切り替えれば、「誰かが調査中」と全員が認識できます。その後、今後の対応についてメモを追加します。このメモには、調査に協力してほしい人物がいれば、その人物について言及できます。
チャンさんが「ジョセフ・カールソンさん、先週のレギュレーターの故障の詳細を送ってください」と書いたとしましょう。チャンさんはこれが何か関係があるかもしれないと考え、ジョセフさんから詳細を聞き出そうとしています。これを保存すると、いくつかのことが起こります。まず、状態が「調査中」に変更されます。
その後、ジョセフは、言及されていたため、JMP Live 内でメールと通知を受け取り、チャンが彼に情報を要求したことを知り、ここで直接またはオフラインでその情報を提供することができます。
ここで「保存」をクリックします。もう一つお気づきかもしれませんが、この管理図の警告は以前は赤い丸でしたが、今はオレンジ色のひし形になっています。これは調査中であるためです。こちらはまだ未解決です。こちらについては誰も調査していません。誰かが調査したいと思うかもしれません。
ポイントにマウスオーバーすると、何が起こっているか、誰が担当しているか、ステータスはどうなっているか、発生したメモなど、あらゆる情報が表示されます。ポイント内で何が起こっているかを簡単に確認できる便利な機能です。
さて、ジョセフがチャンに必要な情報を提供し、チャンがレギュレータの故障が原因だと結論付けたとしましょう。チャンは後でここに戻ってきて、「これはレギュレータの故障でした」と言い、対処済みとしてマークして保存すれば、緑色の四角になります。繰り返しますが、これはもう心配する必要がないことを明確に示しています。何が起こっているのか、私たちは知っています。
さて、管理図自体のサイドパネルの警告にはまだ感嘆符が付いています。これは、管理図に関する未解決の警告が残っているためです。これも誰かが対処する必要があります。
チャンさんが先に進み、この件も自分に割り当てて「対処済み」とマークし、「同じ問題があります」と報告したとしましょう。彼女はこの変更を保存します。すると、両方の管理図の警告が緑色の四角で表示されます。
これで、左側のパネルですべての問題が解決され、JMP Liveでこの管理図が表示される場所に緑色のチェックマークが表示されます。これは、この管理図に問題がないことを示しています。すべて順調です。もう誰も心配する必要はありません。
これはJMP Log 19の新機能である管理図トリアージプロセスです。このプロセスについては、マイケル・ゴフ氏による詳細な講演もございます。ご興味がありましたら、マイケル・ゴフ氏の講演もぜひご覧ください。
さて、管理図の警告と並んで、品質とプロセス管理の分野で私たちが取り組んでいる関連トピックとして、プロセススクリーニングがあります。ここにある他の項目をいくつかクローズアップしてみましょう。半導体能力サンプルデータテーブルを開き、そこに含まれているプロセススクリーニングスクリプトを実行します。このスクリプトは、このテーブルに記録されているすべての異なるプロセスとそのステータスを示すテーブルを生成します。その後、目標プロットを追加したり、プロセスパフォーマンスグラフを追加したりすることができます。
さて、このレポートをJMP Live 18でパブリッシュしたらどうなるか見てみましょう。ブラウザーに戻って上部を見てください。これは先ほど作成したレポートと全く同じものですが、JMP Live 19ではなく18でパブリッシュしたものです。何が表示されるでしょうか？クリックしても、まだ何も起こっていません。特に何も起きていません。下にスクロールすると、目標プロットとプロセスパフォーマンスグラフがここに表示されます。
しかし、目標プロット内の点をクリックしても何も起こりません。インタラクティブ性も全くありません。他の項目も選択されず、他のグラフでも選択されません。JMP Live 18では、JMPに期待される動作が全く起きません。
JMP Live 19にパブリッシュして、改善されているか確認してみましょう。JMPに戻り、「ファイル」→「パブリッシュ」→「JMP Liveへのレポート」を選択します。これがレポートです。新しいレポートをパブリッシュします。「Process Screening」フォルダにパブリッシュします。タイトルは問題なさそうです。説明を追加する必要はありません。このまま進めましょう。繰り返しますが、新しいデータはパブリッシュしたくありません。JMP Liveに既に存在する他のデータを見つけたくありません。同じデータではない可能性があります。それではパブリッシュします。
数秒かかりますが、完了です。この「結果の公開」ダイアログでもう一度「開く」をクリックすると、ブラウザのJMP Liveで開くことができます。これで完了です。見た目はほぼ同じですが、例えばここでNPN9をクリックすると、選択状態になり、右側にNPN9プロセスの管理図が表示されます。
この管理図をNPN6プロセスと比較したいとします。複数選択して比較できます。PNPも試して、3つ表示してみましょう。グラフ上で任意の数のプロセスを選択でき、右側にそれぞれの管理図が表示されるので、比較して、類似点がないか確認できます。そういったことが行えます。
さて、目標プロットとプロセスパフォーマンスグラフはどうでしょうか？ いちいち一番下までスクロールして、全部スクロールして見なくてはいけません。これらは同じレポート内の別々のタブにまとめています。目標プロットをクリックすると、目標プロットが表示されます。そして、これら3つの管理図もここにあります。濃い点が3つのポイントです。そのうち2つは目標プロットセクションにあります。これらは順調です。こちらは、もう1つはここから外れています。
ここをクリックすると、別のポイントセットを選択して確認できます。4つか5つのプロセスを見てみましょう。4つあると思います。これらを選択して管理図を表示し、比較することで、なぜどれも目標を達成していないのかを理解することができます。
同様に、プロセスパフォーマンスグラフに移動すると、目標プロットで選択した4つのポイントが下に表示されます。これらをもう見たくない場合は、クリックして閉じ、こちらにあるポイントをクリックできます。このポイントをクリックしてみましょう。そのポイントの管理図が表示されます。
JMP Live 19 のプロセス スクリーニングでは、よりインタラクティブなエクスペリエンスが得られます。プロセス スクリーニングが気に入っている場合、またはプロセス スクリーニングを使用している場合は、JMP Live 19 を使用してプロセス スクリーニングを組織全体に配布し、ここで説明したようにインタラクティブにすることができるかどうかを確認してください。
これらはJMP Live 19の新機能の中でも特に目立ったものです。ここでは、使いやすさやユーザーインターフェース全般の改善点について少しお話ししましょう。特に注目されたのはホームウィンドウです。JMP Live 18に戻り、JMP Live 18のホームウィンドウを見てみましょう。
あまり明確に定義されていません。アクセス可能なすべての投稿が、最終更新日時の降順でリスト表示されるだけです。最新の投稿が最初に表示され、最も更新の少ない投稿はその下に表示されますが、それ以外はあまり表示されません。
JMP Live 19は、より明確に表示できるようになりました。「最近表示した項目」セクションを設けました。昨日何かを閲覧し、今日また戻ってきたら、その内容について会話中になっているかもしれません。すぐに戻って続きを見たい場合もあるでしょう。
最近閲覧した項目を常に表示しておくことは非常に重要です。ここでは最初の6件が表示されていますが、「すべて表示」をクリックすると、閲覧したすべての項目を、閲覧日時の降順で表示できます。このセクションではブックマークを再利用しています。ブックマーク専用の小さなページがここに用意されており、ここからもアクセスできますが、いくつかはメインのダッシュボード画面にも表示しているので、簡単に確認できます。
繰り返しになりますが、管理図の警告に重点を置いているため、管理図の警告に関するセクションを設け、管理図の警告が表示される投稿をすべて表示しています。興味深いので、「すべて表示」をクリックします。
そのため、管理図のこれら3つの状態は、調査中であり、完全に対処する必要があるため、注意が必要です。このページでは、管理図の警告を含む投稿を、状態に基づいてフィルタリングできます。
完全に対処済みのものや調査中のものには関心がない場合は、誰も見ていない管理図だけを見て、改善が必要な箇所を把握したいのです。誰も注目していない管理図だけを見れば、簡単にアクセスして管理図の警告などを設定できます。これは、皆さんがそうした問題に対処できるよう支援するものです。
一番下には最近更新されたセクションがあり、これはJMP Live 18で見ていたものと同じ内容です。そこに表示されていたのはこれだけで、同じ投稿がここに表示されています。便利なのは、表示範囲を制限できることです。これはJMP Liveのすべてのスペースを対象としています。アクセス権限を持っているスペースの中に、あまり関心のないスペースがたくさんあるかもしれません。必要に応じて、お気に入りのスペースの投稿だけを表示することもできます。
お気に入りのスペースにはまだ投稿がありません。もっとお気に入りのスペースを追加する必要があるかもしれません。どうすればいいですか？私たちが力を入れたもう一つの領域はスペースです。JMP Live 18では、JMP Live上部の「スペース」タブを開いても、すべてのスペースの一覧しか表示されませんでした。そこから見えるのは、実質的にそれだけです。
JMP Live 19 では、[スペース] ドロップダウンをクリックすると、お気に入りのスペース、最近アクセスしたスペースが表示され、[すべてのスペースを表示] をクリックすると、JMP Live 18 と同じディレクトリに戻ります。
スペースをお気に入りに登録するにはどうすればいいですか？ここから、星印をクリックするだけです。これで「JMP Liveの新機能」が私のお気に入りスペースになりました。投稿は「お気に入りスペース」セクションに表示されます。ダッシュボードの左側にあるスペースリストで「JMP Live 19の新機能」が常にここに表示されるようになります。お気に入りスペースに登録したからです。
このセクションには、お気に入りに登録したスペースと最近訪れたスペースが表示されます。このセクションの内容は、様々なスペースを訪れるにつれて変化していきます。
さて、これがJMP Liveのホームウィンドウ、つまりダッシュボードのストーリーに施した変更点の要点です。次回は、更新可能なデータの変更点について、いくつかのセクションに分けて解説していきます。JMP Liveの大きな特徴の一つは、JMP Liveにデータを公開した後、そのデータにアクセスして更新スクリプト（JSL更新スクリプト）を設定できることです。これにより、データベースやディスク上のファイルなど、必要なときにいつでもデータを更新できます。
データを更新すると、そのデータに依存するレポートも自動的に再生成されます。これは、JMP Liveサイトを常に最新の状態に保つための優れた方法です。JMP Live 19では、更新スクリプトとその機能にいくつかの改良を加えました。
リンクデータから始めましょう。ここには4つのレポートと4つのデータテーブルが入ったフォルダがあります。小さな円、リサイクルマークのような円から、これらはすべて更新可能なデータテーブルであることがわかります。この記号はそれを意味しています。
アメリカの都市、テキサス州の都市、ノースカロライナ州の都市、そしてカリフォルニア州の都市があります。これら3つの都市には、Postgresに含まれるアメリカの都市のサブセットが含まれているようです。まずはアメリカの都市のデータを見てみましょう。こちらがデータです。設定画面を開くと、更新スクリプトを確認できます。
これは、米国の都市の人口統計データの更新スクリプトです。AmazonのPostgreSQLデータベースであるRDSデータベースに対してクエリビルダークエリを実行するようです。Amazonにアクセスし、米国全50州のデータを取得します。たくさんの列があります。データを取得した後、各レコード、各都市、そして各州における女性、男性、退役軍人の割合を計算するポストクエリスクリプトを実行します。
これはかなり複雑なクエリですね。データを取得するためにRDSにアクセスする必要があります。それは良さそうです。しかし、テキサス、ノースカロライナ、カリフォルニアといった他のデータテーブルも持っていますが、これらは実際にはこの米国都市テーブルのサブセットにすぎません。
できれば避けたいですね。というのも、これらの他のテーブルはPostgresを経由してRDSへデータを取得する必要がありますが、私は既にRDSからデータを取得していますし、計算列の作成など、いくつかの作業も行っています。必要な他のテーブルで同じ作業を重複させたくありません。
私がやりたいのは、これらの他のテーブルについて、まずここにあるデータから始めて、状態に基づいてサブセット化することです。JMP Live 19では、それが可能です。
テキサス州を例に挙げましょう。こちらがテキサス州です。設定を見てみましょう。テキサス州の場合、「参照可能なデータテーブル」と呼ばれるものを追加できます。長い名前ですが、実際にはリンクされたデータテーブルを意味します。「追加」をクリックすると、JMP Liveシステム上の他のデータが表示され、そこから何かを選択して保存すると、参照可能なデータテーブルのリストに追加されます。
JMP Live のこのリストにあるテーブルはすべて、更新スクリプトで参照できます。1つのアプローチとして、例えばこのテーブルのように、3つか4つのテーブルを1つに結合したいという場合が考えられます。
そういったことをやってみたいと思うかもしれません。今回の場合は、アメリカの都市名を取得し、不要なものを削除して、関心のある州に基づいて設定したいだけです。ここで行ったのはまさにそのことです。更新スクリプトでは、クエリビルダーのようなことは何もしていません。「Postgresテーブルからアメリカの都市名を取得し、『州コードがテキサス』に基づいてフィルタリングする」というだけです。必要なのはこれだけです。
RDSなどを使う必要はありません。ノースカロライナとカリフォルニアのテーブルにも似たような更新スクリプトを用意しています。これはどういうことでしょうか…
これらすべてが含まれているフォルダに戻りましょう。つまり、Postgresのテーブルから米国の都市にアクセスして更新し、リンクデータに戻るということです。このテーブルが更新されるたびに、それに依存する他のテーブルも更新されます。なぜなら、それらはすべてこのテーブルに依存しているからです。このテーブルが更新されるたびに、他の3つのテーブルも更新されます。
州別の退役軍人データは、この元のデータテーブルに依存しているので、再生成されます。次に、他の3つのテーブルに依存するこれら3つのレポートも再生成されます。
それを削除しましょう。Postgresから米国の都市情報を更新するだけで、他のすべてのデータテーブルとレポートも、この更新による新しいデータが利用可能になり次第、更新または再生成されます。たった1回のクリックと1回の更新で、データとレポートが詰まったフォルダ全体を更新できました。
私たちが行った、よりシンプルな小さな変更をいくつかご紹介します。この「州別退役軍人」レポートを開いてみると、更新可能なデータがあることがわかります。この表のデータも更新可能です。これは米国の都市の表で、スケジュールが設定されています。毎週金曜日の午前8時に更新されます。つまり、今から3日後のことです。
データテーブルの更新時期については、これまでも常に表示してきました。スケジュールを詳しく確認しなくても、次回の更新イベントがいつになるかが分かります。3日後というのは、ここには3つか4つの異なるスケジュールが登録できるからです。どのスケジュールが次に実行されるのかを把握するのは、それほど簡単ではないかもしれません。
上の方に「次回更新は3日後です」と表示されていますが、これはデータテーブルについてです。レポート自体についてはどうでしょうか？本当に重要なのは、このデータを使用するレポートです。
さて、すべてのスケジュールを確認して、どのデータが最初に更新されるかを判断します。つまり、更新された直後にレポートが生成されます。レポートを表示しているだけの場合は、上部を見れば、このレポートが3日後に再生成されることがわかります。これは、レポートが依存する次のデータが更新される日だからです。
これは、レポートを確認し、いつ次に更新されるかを把握するための、よりシンプルな方法です。更新スケジュールについて言えば、更新スケジュールに戻りましょう。新しい更新スケジュール、つまり追加の更新スケジュールを作成しましょう。例えば、午前8時に更新を開始したいとします。
繰り返したいのですが、JMP Live 18では繰り返しのドロップダウンメニューを開くと、最小の数字は5分でした。繰り返し実行のスケジュールを変更できる最頻値は5分でした。
JMP Liveでは、少し制限が厳しかったと感じていました。JMP Live 19では、10秒まで任意の秒数を指定できるカスタムオプションがあります。データの更新が速く、どうしても10秒ごとに更新する必要がある場合は、そのように設定できます。今回の場合は30秒とします。30秒なら、2分間にするには120秒と設定できます。
リフレッシュスクリプトの実行スケジュールを非常に柔軟に正確に計算できるようになります。これはキャンセルしてください。特に必要ありません。リフレッシュスクリプトで行った他の小さな変更をいくつか紹介します。
これまで、更新スケジュールとJSLを使った作成方法についてお話してきましたが、JSLよりもPythonの方が得意な方が多いことは承知しています。JMP 18では、JMPはPythonの使い勝手が大幅に向上し、Pythonで記述されたスクリプトを実行できるようになりました。
JMP Live 19では、この機能をJMP Liveに導入しました。こちらの地震テーブルを見てみましょう。これは地震情報のテーブルで、更新機能があります。「All Day」というデータがあり、更新スクリプトが入っています。
下の方を見て、JSLをよくご存知なら「これはJSLっぽくないな」と思うかもしれません。もちろん違います。これはPythonです。リフレッシュスクリプト用の言語セレクターが追加されました。JSLかPythonを選択できます。Pythonを選択した場合は、ここにPythonスクリプトを記述するだけです。
いくつかやらなければならないことがあるので、少し詳しく説明しましょう。もちろん、いくつかのライブラリをインポートしています。これらはJMPがPythonをJMPで使いやすくするために提供しているPythonライブラリです。2つあり、3つ目はJMP Utilsです。JMP Utilsを使うと、必要なPythonライブラリをインストールできます。
今回は、Pandasライブラリをインストールして、リフレッシュスクリプトでPandasデータフレームを使用できるようにします。インストールしてインポートします。次に、Pandasデータフレームを使ってウェブサイトからCSVファイルを読み込み、データフレームに保存します。そして、マグニチュード2以上の地震だけを取得するようにサブセット化します。あまり意味のない小さな地震は取得したくないのです。
これを取得してサブセット化し、JMPとJMP Liveに戻すには、最終的にはJMPデータテーブルにする必要があります。JMPには、データフレームを取得してJMPデータテーブルに戻すユーティリティが用意されています。JMP Pythonライブラリからfrom data frameを呼び出すだけで、データテーブルが作成されます。これは、Pythonで更新スクリプトの結果としてJMPにデータを返すための構文です。
少し複雑ですが、Pythonに慣れている方であれば、Pythonを使い続けることができます。早速実行してみます。このテーブルを更新すると、Pythonスクリプトがデータを正しく更新しているのがわかると思います。
あと数秒で完了です… さあ、完了です。正常に実行されました。履歴を確認すると、更新に成功したことがわかります。それから、戻ってレポートを見てみると、1、2時間前に実行したので、あまり変化がないように見えます。ここ数時間で地震の状況はそれほど変わっていないと思いますが、更新されたデータでは地図はこのようになっています。
Python がお好みであれば、JMP Live の更新スクリプトに Python を使用できます。
こちらは更新スクリプトが入った別のデータテーブルです。これを実行して何が起こるか見てみましょう。その後、何が起こっているのかをお伝えします。この更新スクリプトを実行します。動作するかどうか確認します。もちろん、この説明から、うまくいかないだろうとお分かりいただけると思います。失敗しています。
19では、更新スクリプトが失敗した際に、失敗の原因を調べるために履歴を確認する手間を省くため、失敗に関するエラーメッセージを更新スクリプトと同じパネルに表示するようになりました。他の場所に移動する必要はありません。エラーメッセージを見れば、何が問題だったのかが分かります。
ADDIN_HOME、com.jmp.unitconversion というファイルをインクルードしようとしたようです。つまり、この更新スクリプトは特定のJMPアドインが利用可能であることを前提としており、そのアドインのコードの一部を使用できるということです。JMP Liveの更新スクリプトでアドインを利用できるようにするにはどうすればいいでしょうか？ 実は、可能です。2つのステップで完了しますが、手順は以下のとおりです。
まず、管理者がJMP Liveの管理設定にアクセスします。少し下にスクロールすると、管理者から「これらの4つのアドインは、更新スクリプトに含めることができます。審査済みで、調査済みです。安全です。問題ありません。」と通知されたアドインの一覧が表示されます。
アドインの zip ファイルをアップロードするだけで、それが JMP Live に保存されます。その後、更新スクリプトがそれらのアドインの 1 つを使用すると、更新スクリプトが実行されている JMP Live のインスタンスにそのアドインがインストールされ、更新スクリプトが実行されます。そして、それが完了すると、当然ながら、更新スクリプトの実行ごとに JMP セッションが切断され、再起動されます。
再起動すると、そのアドインはJMPセッションに残りません。JMPセッション内では、更新スクリプトが実行されている間のみ有効です。これにより、ある人が追加したアドインが他の人の更新スクリプトに影響を与えることを防ぎます。競合が発生する可能性があるため、可能な限り回避したいと考えています。
これがステップ1です。管理者は「例えば、単位変換アドインを更新スクリプトで使用しても構いません」と許可する必要があります。これは既に行われています。別のブラウザに戻って下にスクロールすると、更新スクリプト領域に割り当てられたアドインのセクションがあります。「割り当て」をクリックすると、先ほどと同じ4つのアドインのリストが表示され、更新スクリプトで実行を許可するアドインを選択できます。
単位変換を選択して保存します。下に表示されます。このデータを更新すると、20秒ほどで完了するはずです。アドインが利用可能になり、ここに追加しようとしているファイルも見つけられるので、成功するはずです。
できました。エラーは見当たらず、エラーメッセージも消えました。履歴を確認すると、データが更新されました。成功したようです。すべて順調です。
更新スクリプトで実行する必要があるアドインがある場合は、それを実行する機能があります。ここで重要になるのは、JMP Live が作成し、他のユーザーが作成できるデータコネクタです。これらはアドインとして配布されます。データコネクタを使用する必要がある場合は、更新スクリプトにアドインを追加できるようになりました。ここでアドインをインストールして、更新スクリプトで使用できます。
さて、これで更新スクリプトのセクションは終わりです。JMP Liveでデータ更新後にレポートを再生成するレポートスクリプトについてはどうでしょうか。何か変更しましたか？
ついに実現しました。JMP Live 19の私のお気に入りの機能の一つです。こちらはアヤメのデータの等高線図です。見た目は悪くないのですが、データにもっと等高線があるかどうか確認したいと思っています。これは等高線のレベルが1つだけのように見えます。2つ、3つにレベルを増やして、データからもっと等高線を引き出せるかどうか確認してみたいと思います。
どうすればいいのでしょうか？実は、この表を再生成するスクリプトは、レポートをパブリッシュするたびにJMP Liveにパブリッシュされています。しかし、JMP Live 19までは読み取り専用でした。何もできず、変更もできませんでした。この等高線図で使用されている等高線の数を変更したい場合は、JMPに戻り、実行した元のスクリプトを探し、等高線の数を変更して再実行し、このスクリプトの上に重ねてパブリッシュして新しい値を取得する必要がありました。
少し面倒だったので、JMP Live 19では、データテーブル更新スクリプトパネルに似ていますが、レポート再生成スクリプトパネルなので、これを使ってレポートを再生成できるようになりました。これを開いて、レベル数を1から3に変更して保存します。保存すると、スクリプトが変更されたため、「レポート再生成」ボタンが有効になります。
「レポートを再生成」をクリックして、変更が実際に期待通りに機能しているかテストしてみましょう。どうやら期待通りのようです。等高線が1つではなく3つになりました。この子たちでそれが分かります。まさに私が望んでいた通りの見た目です。これで完了です。JMPに戻らなくても更新できるようになりました。
私がよく使うもう一つのユースケースは、ダイヤモンドのデータレポートです。こちらはカラット重量で価格が表示されています。そして、カラーとクラリティのデータフィルターがあります。私の記憶が正しければ、ダイヤモンドには4Cが関係しています。カラット重量、カラー、クラリティ、カットです。カットはどこにあるのでしょうか？データを見ると、カットが含まれていることがわかります。
このレポートを作成した人が、公開前にスクリプト、つまりデータフィルターにそれを組み込んでいなかっただけです。ありがたいことに、今はスクリプトを修正できます。スクリプトを開いて、もう一度大きくしてみましょう。スクリプト内のデータフィルターを見つけて、「切り取り」、「プル」、「切り取り」を追加するだけです。保存します。もう一度、再生成されます。有効にします。クリックしてください。
更新されたレポートの一番下に「カット」があります。「エクセレントカット」だけを見たい、と言えばいいんです。「理想的なカットは無理だけど、エクセレントならいい」と。エクセレント品質のダイヤモンドが欲しいので、それを選択します。これで、他の基準に加えて、その基準に基づいてフィルタリングできるようになりました。
本当に便利な機能は、リフレッシュスクリプトを編集できる機能です。もし期待通りの結果にならない場合は、微調整して理想通りに仕上げることができます。
さて、最後にもう一つ、JSLについてお話します。ご存知か分かりませんが、JMP Liveではスクリプトを使って様々なことができます。スクリプトでJMP Liveにレポートを発行したり、データを更新したりできます。JMP Liveを使えば、JSLで様々なことができます。
JMPに戻って、このダイアログボックスを閉じましょう。JMP Live 18で動作するスクリプトを以下に示します。
チーズ製造会社とチーズ生産会社を経営しており、3つの工場を持っています。ヒューストン、マンチェスター、上海の3つの工場です。このスクリプトは、各工場の能力レポートを作成し、JMP Liveに出力します。これにより、各工場の工程能力に差があるかどうかを確認できます。
これらすべての工場で、JMP Live 上に保存されている1つの仕様限界ファイルを共有しています。仕様限界を一元管理するには、JMP Live 上のファイルに保存するのが便利です。そうすれば、誰もが同じファイルを参照でき、異なる工場間で一貫性を保つことができます。
これが私のスクリプトです。結果がどこに保存されるか見てみましょう。JMP Liveに戻って、ここにあるフォルダを開いてください。JMP Liveには「Pads」というフォルダがあります。JSLでは「Pads」というフォルダで、ヒューストン、マンチェスター、上海の各工場のフォルダがあります。
JMPにどうやって伝えればいいのでしょうか？JMPのスクリプトでこれらのフォルダをどうやって識別すればいいのでしょうか？名前で呼べばいいと思うかもしれません。しかし、JMP Live 18ではそれができませんでした。フォルダに何かを入れるには、フォルダを開いてIDを取得する必要がありました。IDはタイトルバーの上にあるので、そちらで確認するか、こちらの詳細ページからコピーしてJMPに取り込んでそこに入れなければなりませんでした。
少し手間がかかります。スクリプトにIDを入れているので、スクリプトのドキュメント化がうまくいきません。もちろん動作しますが、スクリプトにIDを入れる必要があります。今回の場合は、植物の名前をマッピングしています。自然な植物の名前を使って、すべてを生成しています。
でも、JMP Live で作業を始めると、植物の名前をIDにマッピングして、どのフォルダに保存すればいいのか分からなくなってしまいます。このスクリプトを見ただけでは、どこに保存されているのかよく分かりません。親フォルダって何？ 分かりにくいですね。
これは、JMP Live 18 と JMP Live 19 でも確実に動作します。19 で行ったことはすべて 18 と互換性があります。ただし、18 では少し異なる方法で行う可能性があります。
2つ目のスクリプトを紹介しましょう。JMP Live 19では、別のアプローチ方法があります。JMP Live 19では、WindowsやMacのファイルシステムと同じように、パスとフォルダ名を使用できます。他の場所と同じように、ファイルシステム内を移動できます。
振り返ってみると、このフォルダの名前は「What's New」「JMP Live 19」で、フォルダ名はJSLでは「07paths」です。JMPに戻ると、まさにこの画面が表示されます。
JMPに指示しています。JMP Liveに接続して、これらのすべてのパブリッシュのベースフォルダを取得するには、ライブ接続にこのパスを持つフォルダを取得するように指示するだけです。JMP Live 19の新機能は、JMP Liveで確認したとおりです。自己文書化されています。これが私のスクリプトに含まれています。
次に、さまざまな製造工場をループして、レポートを配置するサブフォルダーを取得する場合は、ベース フォルダーから、ヒューストン、マンチェスター、または上海など、工場と同じ名前のサブフォルダーを取得し、そのフォルダーにコンテンツを公開するだけです。
ドキュメントが充実していて、わかりやすく、植物の名前も覚えやすいです。IDは覚えられないので、IDを使うときよりも、JMP Liveでパスと名前を使って参照する回数がずっと少なくなります。
IDを取得してスクリプトに組み込むという作業を何度も繰り返すことになりますが、これでスクリプト作成が少しスムーズになります。このJSLスクリプトを実行すると、3つの異なる工程能力プロットが作成され、JMP Liveの適切なフォルダに出力されます。
「新着投稿を表示」に行くと、ヒューストンのCapability File、マンチェスターのCapability File、そしてこちらは上海のCapability Fileがあります。何らかの理由で再生成されているようですが、すべて表示されています。
ID を使用する代わりに、パスと名前を使用して JMP から JMP Live をスクリプト化する方法が、ほんの少しだけユーザーフレンドリーになると思います。
さて、これでJMP Live 19の新機能に関するプレゼンテーションは終了です。重ねてお礼申し上げます。私の名前はEric Hillです。メールアドレスはeric.hill@jmp.comです。
ここで紹介した資料についてご質問がございましたら、遠慮なくご連絡ください。ご質問にお答えしたり、適切な方向にご案内したりいたします。
