スクリプティング：一般的な上位互換性ほぼすべてのリリース（7年以降）では、新しいバージョンではスクリプトが機能しなくなったという顧客からの電話があります。同様の電話がかかりますか？
カスタムスクリプト（組み込みの生成されたスクリプトではなく、このチェックがあるはずです）に対して、より良い上位互換性チェックがあるのではないかと思います。明確にするために、ソフトウェアは自然に進化するので、後方への機能については話しません（別名JMP 15スクリプトはJMP 13で実行されません）。しかし、私が期待する消費者/ユーザーとして、JMP 14で記述したスクリプトはJMP 15でも実行されます。
アーリーアダプターは、これを早期に知り、問題をメーリングリストに送信する1つの方法です。ただし、大きな問題があります。ユーザーは通常、早期導入者で互換性チェックを行う時間がないため、特にバージョン7〜9がある場合はそうではありません。これは、ソフトウェアベンダー側で行う必要があります。それは、ほとんどの場合、顧客が不満を言うことでもあります。「彼らの仕事ではない」と私はそれに同意する必要があります（ほとんどの場合）。
では、顧客から同様の苦情がありますか？上位互換性を確認する現在のプロセスは何ですか？ここでいくつかのケースと提案を収集し、何ができるかを提案するとよいでしょう。（また、対応する開発者とのキックオフセッションでこれについて議論するかもしれません-プレナリーでそれらの問題に対処できるQ＆Aを覚えていますが、最後の質問は3年前と信じていました-2020年のSEだけのためですか？）。
おかげで、
マーティン
PS：私がこれを目立つようにした理由は、100以上のライセンスを持つ製造業の顧客が、JMPから他のソリューション、さらにはオープンソースに移行することを長年考えていたためです。
再：スクリプト：上位互換性全般こんにちはマーティン、
FWIW、私の経験では、前方互換性の欠如は、ほとんどの場合、レポートから物事を引き出してさらに操作することに関連しています。あなたは、ソフトウェアが「自然に進化する」ことを期待するのが合理的であると言いますが、好むと好まざるとにかかわらず、レポート構造の変更はこの欲求のほとんど避けられない結果です。実際にスクリプトを多用している顧客にこれを指摘するには、常に苦労するべきです。
ご存知のように、「実稼働」で使用されるソフトウェアの場合、アップグレードされたソフトウェアを「ライブ」にする前に徹底的にテストするステージング領域を持つことは非常に一般的であり、必要です。この規律は、JMPが「単なる」デスクトップソフトウェアであるという事実と矛盾しているように見えるかもしれませんが、（あなたのメッセージが示すように）リスクは実際に現実のものであり、使用パターンが要求するときにユーザーがこのようにJMPを見るのを支援する必要があります。
要するに、この緊張は、JMPが非常に機能的であるという事実の副作用です。重要なJSLコードベースに優れた産業用ソフトウェアエンジニアリングプラクティスのサポートを与えないことのリスクと結果を顧客に警告するより良い仕事をすることができるし、すべきだと思います。R＆Dは、レポートに依存しない方法ですべての必要な値を取得するためのメソッドを提供できますが、これは私が知っているロードマップにはありません。いずれにせよ、JSLプログラマーが評価する柔軟性の一部を奪います非常に。
あなたのように、これに関して私たちがトラブルに巻き込まれた他の例について聞いてみたいです。。。
乾杯、
イアン
再：スクリプト：上位互換性全般こんにちは、マーティン！
TL; DR：
ポイント1： 通常、バージョン間のコードブレークは、人々がJSLのベストプラクティスを順守しておらず、防御的にスクリプトを記述していないためです。ポイント2： バージョン間のソフトウェアパフォーマンス（自社開発またはその他）を検証するのは、常にお客様の責任です。他の製造ツールと同じように扱う必要があります。これらはすべて、生産にリリースされる前に吟味されます。
ロングバージョン：
コメントをリフするだけ @ian_jmp made –ほとんどの場合、バージョン間のコードブレークは、JSLのベストプラクティスに従っていない（または追いついていない）人によるものです。動作するコードは簡単に解読できますが、よく考えられていません。マーク・ベイリーはそれを「防衛スクリプト」と呼んでいます。既存のレポートからプルする人々のイアンの例は、特に表示ツリー全体を下付きにする場合の古典的な例です。このためのベストプラクティスは、アウトラインボックス名をローカルランドマークとして使用し、次に下付き文字を使用することです（頻繁に変更されないため）。
また、バージョン間でオーバーホールを行う機能に依存するJSLをビルドするいくつかのインスタンス（自分自身を含む）に遭遇しました。私にとって、JMP 14で出てきたRecodeの変更は、私が維持していたアドインの一部を壊しました。その場合、私はコードを機能させるために何かをしました。別の（顧客）例は、誰かがデータベースでODBCに準拠していない名前を使用していた場合です。バージョン間でODBCを強制すると、スクリプトが破損しました。ここでは、誰かが標準に従わず、彼らはそれのためにやけどしました。重要な点は、JSLを作成するためのベストプラクティスに従うコードを作成すれば、顧客が問題に遭遇する可能性が低くなることです。そうした場合、JSLがバージョンを壊すことはほとんどありません。防御的なスクリプト作成に対する考え方で書いたもののほとんどは非常に堅牢ですが、私はまだすべてが機能していることを健全性チェックします。通常、アーリーアダプターのリリースの最後の2つがテストされるまで待機します（JMPへの変更は通常、その時点でかなり安定しています）。
Ianは、バージョン間の移動についても非常に良い点を指摘しました。米国では、厳しく規制されている特定の業界（Pharma、Biotech、Finance、および軍事または国家安全保障アプリケーションを備えた製造業）があります。これらの業界には、新しいソフトウェアまたはソフトウェアの新しいバージョンに対する検証要件があり、ユーザーベースがソフトウェアの動作を確認し、バージョン間で一貫した結果が得られることを文書化する必要があります。私の他の顧客は、バージョン間でコードを健全性チェックする必要があることを知っています。だから、それは本当にその顧客の会社文化の成熟度と規律の問題だと思います（少なくともそこのJSLを生成する人々と）。Ianが言及したテストワークフロー（ステージング、実稼働へのリリース）は、これまでに取り組んだすべての業界（米国、EU、またはアジア）での標準的なプラクティスです。
つまり、JSLがミッションクリティカルである場合、JSLを他のプロダクションソフトウェアと同様に扱い、プロダクションにリリースする前に（ミッションクリティカルなJSLで）JMPバージョンを検証する必要があります。あなたの苦情は主に、それがどのように機能するかを理解していないエンジニアリングコミュニティの一部から来ていると確信しています。ツールの性能と他の部品とのマッチングを徹底的にテストする前に、新しい機器を生産にリリースするかどうかを尋ねることができます。「いいえ」と答えます。その時点で、ソフトウェアはツールであり、同じように扱われます。
フォローアップ思考
これについてもっと考えます-JSLのベストプラクティス（関数と式、スコープ、名前空間、コードに大量のコメントなど）、物事が壊れたときにデバッグするのが簡単です（それは壊れます）。 そのため、問題の顧客には、時間の経過とともに有機的に成長した、不適切な形式の脆弱なJSLが存在するようです。 それは恐ろしくコメントされていると思われ、それを書いた人は次の場所に移動したか、それを修正する方法がわかりません（私はこれらのフランケンスクリプトと呼びます）... その場合、JSLを知っている人をSAS Ed JSLコースに送り、ベストプラクティスを復習し、問題のコードを最新化するためにそれらを緩め、問題のJSLを追加するためにいくつかのSOPを配置することをお勧めしますソフトウェア検証テスト計画に。
再：スクリプト：上位互換性全般これまでのすべてのコメントに同意します。恐ろしい「生産」コードが常に表示されます。私はそれが現在のバージョンで機能するとは信じられません。これらのユーザーは、JMPのスクリプトの作成方法を学習していません。これは、一般的なコンピュータープログラミングとは異なります。単なる構文ではありません。彼らはただハックします。（私は「ハッカー」という言葉を敬意をもって使っています。このアクティビティは異なります。）彼らは何をしているのかわかりません。
レポート層へのアクセスを妨げるJMP UIの変更に関するコメントについては、多くのユーザーは安全なコーディングを実践していません。これらの問題を最小化または排除する方法がありますが、その方法は脆弱なコードを生成します。
再：スクリプト：上位互換性全般これまでのコメントに感謝します。実稼働に入る前のテストとセーブ/ディフェンスのコーディングに関するすべてのポイントに同意します（おそらくユーザーは気に入らないでしょうが;））。これは、whatecver言語のスクリプトを使用するユーザーおよび会社の責任において決定的に責任があります。
ただし、より重要な観点からも議論を進めたいと思います（最後に、顧客への共通のメッセージと、顧客に販売するためのより堅牢な自動化プロセスをせいぜい持っていることを望みます）：
ツールが構築されているプログラミング言語に依存しているソフトウェア会社から来て、JSLがバージョンからバージョンへと変化していることを知る頻度に驚く。私の過去の人生では、これらの問題は文書化されていない機能と機能でのみ発生し、色のテーマやオブジェクトツリーやメソッドのその他の設定やオプションでは発生しませんでした。また、すべての機能が最大限に文書化されました。使用可能な入力と出力、このオプション/入力/出力の説明と定義など。スクリプティングガイドとインデックスはどちらもその種類ではありません。もっとこれは基本的な呼び出しであり、あなたがあなた自身を見つけなければならない他のすべての可能なオプションです。
文書化されていない部分はすべて変更される可能性があります-それは簡単な答えでしょう。しかし、それはそれほど簡単ではないと思います。ほとんどの場合、少なくとも「組み込み機能の1レベル下」を少し変更する必要があります。「できること」と「他のすべてはサポートされていない」と言う具体的なドキュメントは提供していません（現在は動作する可能性がありますが、変更される可能性があります）。
プログラミング言語にはこのようなフレームワークが必要です-または、JSLはそのようなプログラミング言語ではなく、再現可能なコードを構築するのは簡単ですが、信頼性が低い可能性があるため、より多くのユーザーに手を差し伸べるためにアプリケーションを作成する現在のプロモーションに注意してください将来のバージョン用。
他の人がこのことについてどのように感じているかを聞くのは面白いでしょう（このトピックについてのダイバーの議論を促進するために、より重要な目的の観点で認めています）、また、日ベース。
再：スクリプト：上位互換性全般最後のポイントは重要なポイントです。JSLは非常に強力ですが、基本的には「プログラミング言語」ではなく、スクリプト言語またはマクロ言語です。オブジェクト指向プログラミングに似た構造を持ち、ある程度その方法で使用できますが、JMPの上に構築されており、GUIでのタスクの自動化またはGUIの拡張を常に目的としています。多くの人は、それを忘れています-これは、製品で物事が変更されたときに忘れていることを意味します-JSLで物事が壊れる可能性があります（特にうまくコーディングしていない場合）。JSLをC ++などの方法で話すべきではありません。厳密に言えば、PythonとRでさえ、JSLよりも密接に関連するプログラミング言語です。ExcelマクロとVBAで線がぼやけているために混乱する人もいるかもしれません。ただし、ポイントは、JSLはプログラミング言語とは異なるスクリプト言語であるということです。
ベスト、
M
再：スクリプト：上位互換性全般こんにちはマイク、
同意します、それはスクリプティング言語であるため、踏み込む必要があります。この議論は、プロセスの自動化またはスクリプト作成を開始する際に人々が考えるように常にガイドする必要がある追加の側面を強調するため、貴重であることがわかりました。JMP JSLトレーニングコースに加えて、「防御的な」スクリプティングのためのJMP関連の他のリファレンスはありますか？
Webで見られる参照のほとんどは、JMP関連ではなく、他の言語を対象としています（もちろん、それらも使用できます）。Mastering JMP Webキャストは、優れたプログラミング/スクリプトスタイルをカバーしていません。ディスカバリープレゼンテーションにとっても興味深いトピックになるでしょうか？
再：スクリプト：上位互換性全般それは私たちが改善できると思う分野の1つです。コミュニティ、スタッフの頭の中、書籍、およびドキュメントには多くの情報がありますが、私が知っている「ベストプラクティス」ドキュメントは実際にはありません。あるはずです。現場であなたが経験している多くの驚きは、この一点にチョークアップできると思います。
@ian_jmp –多分これは技術コミュニティがキックオフ中のサイドバーとしてできることでしょう。
ベスト、
M
再：スクリプト：上位互換性全般私の回答が示唆したように、特に「土地と拡張戦略」の「拡張」部分のコンポーネントとしてアプリケーションを構築することを一般的に推奨しているため、これは私たちがより良くできる分野だと思います。
FWIW、私の個人的な見解は、SEがそれほど傾いていない限り、すべてのSEがJSLに堪能であるべきではないということです。しかし、私はすべてのSEが何が可能か、そしてこれに加えて、どのような優れたプラクティスがどのように見えるか、これを遵守しないことの落とし穴を知っているべきだと信じています。
残念ながら、2020年のキックオフは少し圧縮されており、テクニカルトラックは既に編成されています。したがって、これを処理する別の方法を見つけます。もっと後で。
再：スクリプト：上位互換性全般いくつかのエディションのスクリプトコースに明示的な「ベストプラクティス」の提案を追加し始めました。これらの提案は、改訂のたびに拡張および改良され続けます。学生からは肯定的なフィードバックを得ています。まあ、少なくとも急いでハックしていない学生から。
