| スピーカー |
トランスクリプト |
| セルカイ・オルメズ |
こんにちは、Seagate の Serkay と Fred です。今日は、JSL スクリプトを管理するための JSL エコシステムの構築方法についてお話します。 |
| |
私たちはJSLスクリプトのソースコード(ソース管理)の管理と配布にGitを使っています。これが今日の講演のメインテーマです。 |
| |
それに加え、PowerPoint統合のためのVBA、クラッシュログの収集、そしてユニットテストについてもお話します。概要を簡単にご説明します。 |
| |
まず最初にお話ししたいのは、JSLの歴史についてです。私は約10年間JSLでスクリプトを書いてきました。 |
| |
私たちは今、この場所にとても満足していますが、ここに至るまでにはかなりの時間がかかりました。私たちの経験におけるマイルストーン、これまでに行ったこと、そしてその理由についてお話ししたいと思います。 |
| |
次にGitについて、JSLスクリプトのソース管理にGitをどのように活用し、さらに機能追加を実現したかについてお話します。例えば、Gitを有効にすると、 |
| |
スクリプトの監視などの機能を追加することもできます。これにより、開発者はスクリプトが使用中かどうかを把握し、使用状況を監視できるようになります。 |
| |
そしておそらくもっと重要なのは、ログも収集できることです。スクリプトがクラッシュした場合、開発者はそれを把握し、戻ってバグを修正することができます。そして… |
| |
さらに一歩進んだ機能を追加できます。スクリプトがクラッシュしたことが既にわかっている場合は、自動的にバグチケットを作成することもできます。そのため、そのバグチケットを自動的に作成できます。そして、JIRAやAtlassianなどのトラッキングソフトウェアを使用して、これらのチケットを追跡できます。 |
| |
最後に、これまでに学んだベストプラクティスと教訓をお話ししたいと思います。 |
| |
それで、 |
| |
付録には、これからご紹介するスクリプトのマニュアルも掲載しています。PowerPointに画像をプッシュできるスクリプトです。 |
| |
そのための非常に詳細なマニュアルがあり、ここで説明するすべてのもの、データ、スクリプトが利用可能になることをお知らせしておきます。 |
| |
これらはここの参考文献セクションの公開リポジトリに掲載されているので、必要に応じてそこからファイルをダウンロードできます。それでは、 |
| |
簡単な歴史をここでご紹介します。私はJSLに10年ほど携わっていますが、最初は |
| |
非常に基本的なもので、JSL スクリプトについてはあまり知りませんでした。 |
| |
そして、それをやり始めると、適切なソース管理が必要であり、スクリプトを配布する適切な方法が必要であることに気づきます。 |
| |
JMPのスクリプトの特徴は、導入の障壁が全くないことです。文字通り、手動でプロットを作成してからスクリプトをダウンロードするだけで済みます。スクリプトはあなたのために書かれています。 |
| |
また、JMP.com の JMP コミュニティを使用して質問し、回答を得ることもできます。 |
| |
そしてあなたは…スクリプトがとても効率的で、仕事を効率的にこなしているので、周りの人はそれに気づきます。どうやってやっているのか聞かれたら、「それ用のスクリプトがあります」と言うでしょう。そして彼らは |
| |
「それを私と共有してもらえますか?」と尋ねると、そのつもりはなかったのに、突然開発者になってしまうのです。 |
| |
そして、スクリプトの配布方法も考えなければなりません。最初に思いつくのは、単に添付するだけという方法ですが、これはひどいアイデアで、私はかなり長い間そうしてきました。 |
| |
そして、なぜそれが良い考えではないかは明白です。なぜなら、スクリプトを添付して送信し、翌日には |
| |
修正して再度送信しなければならず、ユーザーが次回もその修正版を採用するかどうかさえ分かりません。つまり、ここではその点を説明しているだけです。 |
| |
最近、同僚からメールが届きました。彼は私が2017年に作成したスクリプトについて言及していました。私はスクリプトにこのように番号を付けていました。 |
| |
バージョン番号は良いアイデアではありません。3年、4年経って戻ってきたら、アップデートをしていないために、まだ3年前のスクリプトを使っている人がいることに気づくのです。 |
| |
この問題を解決する一つの方法は共有ドライブを使うことです。私が共有ドライブで人々とやりとりした経験に基づいて、 |
| |
Discovery Summitsは、多くの人々、多くの企業が利用しているという点が大きな特徴です。そこで開発者は |
| |
スクリプトを共有ドライブにダンプすれば、ユーザーは共有ドライブから直接プルできるようになります。これで配布の問題の半分は解決しますが、ソース管理については何も解決しません。コードに加えた変更を追跡することはできません。 |
| |
これが、私たちがGitに移行した理由です。これは私たちにとって画期的な出来事で、多くの機能を実現できました。Gitを使うと、開発者はスクリプトをリポジトリにプッシュし、 |
| |
ユーザーはGitから直接スクリプトをプルするようになります。これは私たちにとって大きな改善であり、クラッシュログを収集できるようになりました。 |
| |
スクリプトの使い方などです。サミットで学んだことをもう2つお話ししたいと思います。スクリプトスキルの向上に非常に役立ちました。2018年のサミットにも参加し、表現などについてかなり学びました。 |
| |
人々はそれらのプレゼンテーションを戻って聞きたいと思うかもしれません。なぜならそれらはスクリプト作成スキルの向上に役立つからです。 |
| |
私たちにとってもう一つのマイルストーンはテストに関するものでした。昨年のサミットで、スクリプトを公開前に自動的にテストできるユニットテストに関する講演に触発されました。 |
| |
今日は主に統合テストについてお話します。なぜなら、ユニット テストは必須ですが、十分ではないからです。 |
| |
ユニットテストができるので、すべてのモジュールをテストして問題なく動作します。しかし、それらを組み立てると動作しません。ここに示すように、クラッシュします。各引き出しはテストされているかもしれませんが、組み立てると動作しません。 |
| |
開発者に非常に役立つ便利な機能の 1 つは、ログ収集に関するものです。 |
| |
スクリプトがクラッシュしたこと、そしてどのようにクラッシュしたかを把握しておくことは非常に役立ちます。ユーザーからログを収集することで、スクリプトを修正して変更をプッシュすることができ、ユーザーはすぐに修正されたスクリプトを利用できるようになります。 |
| |
最後に、最近リリースした機能は、自動バグ報告です。すでにクラッシュレポートをお持ちなら、その情報に基づいて行動するのはいかがでしょうか?そこで、自動化された |
| |
監視 |
| |
このシステムはクラッシュログを追跡し、自動的にバグレポートを作成するので、開発者はそれらの問題に対処できます。さらに、ユーザーをウォッチャーとして追加することで、誰かが問題に取り組んでいることをユーザーに知らせることができます。これで、問題は解決します。 |
| |
ユーザーと開発者の間の情報ギャップを解決します。 |
| |
これはタイムラインを示しています。 |
| |
個々の項目については、Git から始めて、これを簡単に構築し、Fred にこれについて話させます。 |
| 163084 |
わかった。 |
| |
それで、 |
| |
Gitは単なるバージョン管理システムであり、私は「バージョン管理」という言葉は使いません。実際には、Gitは実質的に無制限のやり直しを可能にすることで、たとえ自分のローカルコンピュータでのみGitを使う場合でも、あなたを助けてくれるのです。 |
| |
過去数週間に行った作業の一部が間違っていたと判断し、数週間前の作業に戻りたい場合に備えて、ファイルのリビジョンを追跡して古いものに戻る機能を提供します。 |
| |
Gitはローカルコンピュータにインストールするソフトウェアです。リポジトリを作成し、そのリポジトリを他のリポジトリに投稿することができます。 |
| |
GitLabやGitHubなどですね。TortoiseGitはローカルマシンで使えるGUIインターフェースで、作業が楽になります。それでは、Serkayさん、次のスライドを開いてください。 |
| |
そこで私が開発者に試したモデルは、ローカルコンピュータ上での使用です。ローカルの開発者には、Gitクライアントをインストールしてもらい、 |
| |
ローカルPC上のファイルのバージョン管理に慣れてきたら、リモートリポジトリに接続できます。 |
| |
GitはリモートリポジトリやSSH、その他の方法で接続し、プッシュすることができます。 |
| |
Gitデータベースのコピーをリモートリポジトリにアップロードします。リモートリポジトリにアップロードされると、HTTPウェブサーバーからJMPに共有できるようになります。 |
| |
URLとHTTP…HTTPウェブサーバーを指定して、そこからスクリプトを読み込むことができます。つまり、共有ドライブの代わりに、Gitリポジトリへのプッシュによって生成されたHTTPウェブサーバーを使用しているということです。 |
| |
そして、その下の箇条書きの項目では、その利点とそれがどのように機能するかを具体的に示しています。 |
| |
次のスライドに進みましょう。 |
| セルカイ・オルメズ |
それで、フレッド、私が引き継いで、非常に基本的な図解の実装をお見せします。スクリプトは「参考資料」から入手できます。 |
| |
それで、 |
| |
これは非常に基本的なコードです。ここで示しているのは、開発者が開発しているコードです。必要最低限の機能です。「Hello World」と表示されるダイアログボックスだけです。 |
| |
開発者がこのコードをユーザーに渡したいとします。つまり、このコードの代わりに、開発者はこのコードをユーザーに渡します。 |
| |
これはリポジトリへのリンクです。つまり、これはそこにあるhello JSLスクリプトのリポジトリです… |
| |
リモートリポジトリにあるファイルです。ユーザーが行うのは、単に…ユーザーが |
| |
URLからスクリプトを取得します。これは静的コードです。変更の必要がないため、開発者はいつでもスクリプトを変更できますが、ユーザーは何もする必要はありません。ここでイラストをお見せしますが、画面を全画面表示に切り替えたいだけです。 |
| |
これはGitHub DesktopというGUIを使ってどのように動作するかを示したものです。インストールして |
| |
ソフトウェアをコンピュータにインストールしてローカルリポジトリを作成すると、変更内容が記録されます。例えば、この例では、hello JSLスクリプトを作成しました。 |
| |
このソフトウェアは変更があったことを認識し、自動的にハイライト表示します。まずローカルリポジトリにコミットします。 |
| |
これでローカルリポジトリにプッシュされ、その後、リモートリポジトリである origin にプッシュされます。次に、リモートリポジトリにプッシュして、ユーザーが利用できるようにします。 |
| |
これを実行すると、ユーザーは新しいコードをプルできるようになります。ここでユーザーロールに切り替えて、このスクリプトをユーザーが実行すると…するとダイアログボックスが表示されます。つまり、リポジトリからプルしたスクリプトを実行していることになります。 |
| |
そこで、PowerPoint にも関連する、より高度なコードを使用して、これをもう少しわかりやすく説明します。 |
| |
JMPで多くの分析を行う人は、それでも一日の終わりに結果をPowerPointに出力したいと考える人が多いです。JMPにはPowerPointに出力するための機能がいくつかあることは知っています。 |
| |
PowerPointに画像を直接アップロードしたいのですが、もう少し洗練されたものが欲しいのです。 |
| |
PowerPointのテンプレートを管理します。PowerPoint内でさらにいくつかの操作を行いたいのですが、スライドごとに画像の数などを決めたいです。 |
| |
それを実行するには、まず JMP を PowerPoint に接続する必要がありますが、これは実際には非常に簡単に実行できます... |
| |
JMPを離れることなく、非常に便利な方法で実行できます。PowerPointの実行ファイルがどこにあるか確認しましょう。通常はProgram Filesフォルダ内にあります。 |
| |
そして、このPowerPoint実行ファイルを実行するバッチファイルを作成します。バッチファイルは実行したいPowerPointファイルを取得し、実行します。つまり、これらすべてをJMPで実行できます。基本的に、これはPowerPoint実行ファイルを検索します。 |
| |
見つかったら、それをバッチファイルにまとめます。また、実行したいPowerPointへのパスも含まれています。 |
| |
そしてマクロなので、PowerPointにはPowerPoint内で管理を行うためのマクロが組み込まれます。これがその方法です |
| |
JMPをPowerPointに連携させるには、JMPをPowerPointに連携させる必要があります。しかし、問題は、このPowerPointファイルをユーザーにどうやって届けるかということです。 |
| |
彼にダウンロードを依頼するのですが、これは理想的ではありません。なぜなら、これを自動的に管理したいと同時に、PowerPointのソース管理も行いたいからです。ですから、PowerPointは適切な候補でなければなりません。エコシステム全体の良い一部である必要があります。外部に公開すべきではありません。 |
| |
もう1つの要件は、スクリプトを実行するたびにPowerPointをダウンロードしたくないということです。つまり、画像リポジトリに変更があった場合、またはPowerPointに何か新しい機能が追加された場合のみ、PowerPointをダウンロードするということです。 |
| |
これを実行するには、JMPのスクリプト、つまり作成日を指定するJMPコマンドを使用します。ここで私が行っているのは、 |
| |
ローカルファイルの日付です。つまり、ローカルのPowerPointがリポジトリにあるものより古い場合は、ダウンロードすることになります。 |
| |
HTTPリクエストを使用してPowerPointをダウンロードし、 |
| |
こんな感じです。ローカルコンピュータでPowerPointファイルを確認します。存在しない場合は、HTTPリクエストを使用してリポジトリから取得します。存在する場合は、日付を確認します。古い場合は、 |
| |
新しいものを入手してください。つまり、PowerPointをJMP環境にシームレスに統合できるため、表や画像などの結果をJMPにプッシュできます。しかも、これらすべてをソース管理を崩すことなく実行できます。ここでデモをお見せします。 |
| |
これは、例えばユーザーに提供するコードになります。繰り返しますが、これは静的なコードです。スクリプトからリモートリポジトリにリンクするURL以外は何も含まれていません。つまり、 |
| |
リポジトリからの JMP スクリプトとそれらのスクリプトは再び利用可能になり、参照から取得できるようになります。 |
| |
開発者側から見れば、これが実際のスクリプトです。開発者が開発したスクリプトです。 |
| |
それをリモートリポジトリにプッシュします。このスクリプトの良いところは、ここでいくつか機能を簡単に紹介しておきたいところです。 |
| |
例えば、これを見てみましょう。これはスタンドアロンのテキストスクリプトなので、PowerPointファイルや追加のスクリプトを配布する必要はありません。 |
| |
別々に。スクリプト内でリンクし、リポジトリ内でリンクします。 |
| |
PowerPointも含みます。このスクリプトが配布全体を管理します。PowerPointを取得します。 |
| |
必要に応じて他の追加ファイルも取得します。すべてがスクリプトにまとめられているので、すべての管理をスクリプトが行ってくれます。さて、これを簡単にお見せしましょう。 |
| |
全画面表示にして |
| |
よく見えるように。これはPowerPointを自動的に起動するデモです |
| |
このスクリプトは、JMPのテーブルからパスを取得します。このテーブルには多くの画像パスが含まれており、それらは特定のケースを参照しています。 |
| |
サーバーでは、これらのパスが取得され、ここで強調表示されているパスだけが取得されて、PowerPoint にプッシュされます。 |
| |
これを実行してみます。このスクリプトは、試してみたいという方のために公開されています。これは完全に機能する便利なスクリプトです。それで、これを実行してみましょう。 |
| |
スクリプトです。繰り返しますが、これはリポジトリを参照しています。つまり、行スクリプトは含まれておらず、リポジトリからプルするだけです。実行すると、コードが取得され、ダイアログが実行されます。 |
| |
これを実行するだけです。詳細は省きますが、実行するとPowerPointが自動的に起動します。 |
| |
PowerPointが起動し、スライドの作成が始まります。20枚の画像が読み込まれ、10~20秒ほどかかります。その後、PowerPointが表示されます。 |
| |
完了です。これが完成したPowerPointです。すべてが自動的に行われ、リポジトリから取得されました。 |
| |
では、次はどうしますか?このPowerPointをどう修正しますか?テンプレートにいくつか変更を加えたいとお考えですね。そして |
| |
詳細は付録で確認できますが、私がお見せしたいのは、 |
| |
PowerPointのスクリプトです。全画面表示に切り替えます。 |
| |
これを実行します。まず、前のスライドで残っていた画像から始めます。 |
| |
私がやりたいのは、要点を説明するためにテンプレートを少し変更することです。それでは… |
| |
マクロを開いて、下にスクロールして変更したい項目を見つけます。ここでは簡単な変更を行います。ポイントを明確にするためにヘッダーの色を変更します。 |
| |
そして |
| |
保存してください。これはリアルタイムで行われます。 |
| |
これを保存し、スライドを削除すると、リポジトリにプッシュされるため、リポジトリへの移動が速くなります。 |
| |
そしてGit GUIを使ってこれをプッシュします。リポジトリに追加されます。 |
| |
すると、ユーザーが利用できるようになります。つまり、すべてのユーザーが即座に変更内容を受け取ることができるのです。そのため、ユーザーにPowerPointの更新などを依頼する必要はありません。 |
| |
これはリポジトリに移動するだけです。 |
| |
そして、JMP に戻ってユーザー モードに切り替え、スクリプトを再度実行すると、新しい PowerPoint が取得されます。 |
| |
もう一度実行すると、 |
| |
スライドを作成すると、スライドが作成されます。そして、ヘッダー行の色を変更するという変更が加えられていることにお気づきでしょう。 |
| |
それで、 |
| |
他に何がありますか? |
| |
スクリプト監視。これは私たちが開発した機能の中でも最高のものの一つだと思います。開発者がスクリプトが |
| |
彼らの脚本…彼の脚本は評価されるかどうか。なるほど。それで、それは実行されるのでしょうか?誰かが定期的に実行しているのでしょうか? |
| |
これが1つのメリットです。もう1つのメリットは |
| |
log...クラッシュログの収集。スクリプトが失敗した場合、JMPのログキャプチャ機能を使用してその失敗を記録できます。そのため、サブルーチンをログキャプチャに挟むことになります。 |
| |
失敗した場合…失敗した場合…失敗のログがこのログに返されます。そして、次に行うことは |
| |
それを try で囲むと、スクリプトはレポートを実行するために存続します。 |
| |
そして、それが空かどうかを確認します。空であれば、クラッシュは全く発生していないため、スクリプトは正常に動作したことになります。 |
| |
しかし、もし空でなければ、クラッシュが発生し、それを封じ込めたことを意味します。ログを取得して報告することができます。その方法はHTTPです。 |
| |
ユーザー ID、スクリプト名、ログノート、クラッシュかどうかなど... |
| |
クラッシュなのか、それとも通常の実行なのか、パフォーマンスメトリクスなど、様々な情報が得られます。つまり、スクリプトに関するデータメタデータを開発者に返すことができるということです。 |
| |
サーバーはログを記録し、サーバーに一連のファイルが格納され、監視できるようになります。これはサンプルです。 |
| |
これはクラッシュログで、日付とスクリプト名が入っています。つまり、このスクリプトは日付に失敗したということです。 |
| |
このクラッシュについてです。これは開発者にとって非常に便利です。戻って問題を修正できるからです。ここでこれを折りたたんで、簡単なデモを行い、どのように修正するかを説明します。 |
| |
どのように |
| |
クラッシュの内容と、それをユーザーに報告する方法を説明します。ここではサブルーチンクラッシュを作成します。未定義のパラメータを作成します。 |
| |
JMPはエラーを出します。「これは定義されていない」と表示され、スクリプトがクラッシュします。そこで、このサブルーチンを呼び出します。 |
| |
ログキャプチャ機能では、すべてがtryの下に挟まれます。そのため、スクリプトはサブルーチンでクラッシュしましたが、全体としては存続し、レポートできるようになります。 |
| |
クラッシュレポートですね。ユーザーには、きちんとフォーマットされた通知を送って、その旨を伝えているのでしょうか?スクリプトがこの特定のエラーでクラッシュしたので、ログを作成し、現在対応中です。これが、ユーザーに伝える通知です。 |
| |
サミットで学んだ重要なことの一つは、自動テストについてでした。以前は手動でテストを行っていましたが、とてもストレスを感じていました。 |
| |
時間がかかる上に、スクリプトの隅々まで把握することができません。小さな変更を加えるだけで何時間もかけてテストするのは不可能です。 |
| |
それで私は自動テストに興味を持ち始めましたが、ユニットテストを行うことが非常に重要だと分かりました。つまり、テストとは個々のサブルーチンのテストを指します。例えば、関数があって、それをテストしたいとします。 |
| |
システムに組み込む前に複数回ユニットテストを実施することで |
| |
個々のモジュールごとに設定できますが、それだけでは十分ではありません。いくつか例を挙げて説明します。 |
| |
例えば、NASAは火星探査機を非常に奇妙なエラーで失いました。ヨーロッパに1つ、火星に2つのソフトウェアチームがあったためです。 |
| |
1つはアメリカで、もう1つはポンドの単位を扱っていました。もう1つは、アメリカで、もう1つはヨーロッパで |
| |
ニュートンを使っていました。ユニットテストは確かに行いました。しかし、コードを組み立ててみると、片方はニュートンを期待し、もう片方はポンドを期待していたため、動作しませんでした。つまり、文字通り |
| |
オービターは、ポンドからニュートンへの換算を忘れただけで、その誤りに気付かなかった。さらに最近では、スターライナーとして、ボーイングがスターライナーを紛失したが、もし換算していれば誤りに気付くことができたはずだと認めた。 |
| |
厳格な統合テスト。そして最終的に重要なのは |
| |
モジュールはスクリプト内で単独で存在するのではなく、相互に通信するため、統合テストが行われます。 |
| |
これはここでの問題を面白く例証しています。2つのオブジェクトを徹底的にテストすることができます。これはウィンドウです。ウィンドウで何が問題になるでしょうか? |
| |
しかし、2 つを組み合わせると、開くことすらできなくなるため、結合されているかどうか、一緒に正常に動作するかどうかを確認するために統合テストを実行する必要があります。 |
| |
ここで、私がどのようにして自動テストを始めたのかを簡単に説明したいと思います。これは特定のケースについてです。 |
| |
正直言って難しいケースです。これはモーダルウィンドウのテストであり、モーダルウィンドウはボタンをクリックしない限り消えません。そのため、 |
| |
ボタンをクリックするJMPスクリプトを作成します。これは人間の行動を模倣するものです。ここで私がやっているのは、テスターを注入することです。 |
| |
モーダルウィンドウです。このアプローチの良いところは、配布できるということです |
| |
このスクリプトをユーザーに公開すると、ユーザーは実際にそこに何らかのテスト ルーチンが含まれていることに気付かないでしょう。 |
| |
テスター用のフックがありますが、これを単独で実行すると、テスト モード パラメータが検索されますが、設定されていません。 |
| |
設定されていない場合、スクリプトはこれをゼロに設定し、テーブル内のすべてのフックを無効にします。そのため、これをユーザーに提供すれば、ユーザーはこのように実行できます。 |
| |
ただし、スクリプトをテストしたい場合は、その上にテスターコードを構築する必要があります。テスターコードはテストモードを1に設定し、テスターも作成します。 |
| |
スクリプトに挿入したいテスターオブジェクトです。例えば、このケースでは、特定の列を選択しています。 |
| |
そしてボタンをクリックして役割を割り当て、スクリプトを実行します。つまり、文字通り人間の行動を模倣しているのです。 |
| |
次に、実際のスクリプトを読み込みます。つまり、テストしたいスクリプトにパラメータを挿入することになります。これでスクリプトが自動的に実行されるので、スクリプトが読み込まれて実行され、ボタンをクリックするとUIが閉じられます。 |
| |
そして、ログ キャプチャ機能で再度実行して、何か問題が発生した場合に障害をキャプチャできるようにします。 |
| |
また、enter try にもこれを記述することで、スクリプトがログを報告し終えるまで動作を続けます。そして、何も問題がなければ空のログが返され、スクリプトが失敗しなかったことを意味します。 |
| |
何か問題が発生した場合、ログキャプチャでそれが分かります。これがその考え方です。 |
| |
それで、 |
| |
我々は持っています |
| |
スクリプトを監視する機能があります。 |
| |
クラッシュのログをキャプチャします。そこで、クラッシュログに基づいて対処しないのはなぜかと考えました。クラッシュログを見ると、何か問題が発生したことが分かります。そしてスクリプトは…ユーザーはスクリプトがクラッシュしたことは明白なので既に分かっていますし、開発者もログが記録されているのでスクリプトがクラッシュしたことを知っています。 |
| |
サーバーに保存されているので、それに基づいて対応できます。しかし、これはまだ閉じたループではありません。ユーザーは開発者がそれを知っていることを知らないからです。このループを閉じるには、自動チケットを作成します。つまり、すでに情報を持っているので、 |
| |
JIRA Atlassianなどのバグ追跡ソフトウェアを使用すると、REST機能を使用できます。 |
| |
サーバーから情報を収集し、チケットを作成し、開発者に割り当てます。また、ユーザーをウォッチャーに割り当てることもできます。ウォッチャーとは、開発者が何かを行うたびに |
| |
バグに関する情報を JIRA に入力すると、その情報がユーザーに返送され、ユーザーに通知されて、誰かがバグに取り組んでいることが分かります。 |
| |
JIRAの種類に応じて複数の方法がありますが、ここでは |
| |
基本的なコードです。これはCurlコードで作成でき、クラッシュログからメタデータを収集してJSLファイルに埋め込み、REST経由で送信して、 |
| |
JIRAは…追跡してくれます。そして、JIRAは、適切に設定されていれば、JIRAは開発者に通知し、場合によっては |
| |
スクリプトがクラッシュしたユーザー。これらはすべて結びついており、開発者は自分が対処すべきバグがあることを把握でき、ユーザーは誰かがそのバグに対処していることを知ることができます。 |
| |
はい。これで締めくくりのメモに移りたいと思います。このプレゼンテーションから得られる教訓についてお話ししたいと思います。 |
| |
Gitは私たちのシステムの礎であり、多くの素晴らしい機能を実現してきました。基本的な機能についてはまだ触れていませんが、 |
| |
これは当然のことですが、共同作業も可能になります。複数の人が同じスクリプトで作業する場合、 |