これは、ソフトウェアアプリケーションの新機能の命名に関する課題についての4部構成シリーズの最初の記事です。特に、命名が不十分な場合の結果についてです。 シリーズの第一部では<\/STRONG>、新機能の名前がその機能の動作を明確かつ簡潔に説明しているケースを見ています。 <\/EM>シリーズの第二部<\/EM><\/A>では、その同じケースで、新しい機能が元の機能の動作を変更した場合を見ています。 <\/EM>シリーズの第三部<\/A><\/EM>では<\/A>、この変更された機能に対応するためにドキュメントがどのように変わったかを見ています。 そして最後に、シリーズの第四部<\/A>では、これらすべてがエンドユーザーと開発者にとって何を意味するのかを議論しています。<\/EM><\/P><\/P>ソフトウェアアプリケーションで新機能に何と名付けるかを決める際には、比較的短くて比較的説明的な名前が通常は勝ちます。 本当に理にかなっています。誰がヘルプやスーパー・デコーダーリングを使って、その機能が何をするかしないかのアイデアを得たいと思うでしょうか。 しかし、短すぎたり説明的すぎたりすることにはリスクがあります。前者は重要な限定条件や細かい注意書きが省略されることが多く、前者と後者を組み合わせると通常、ユーザーは誤った理解、つまり機能が何をするかを知るのではなく推測してしまうという誤解に陥ります。 新機能に名前を付ける行為自体が十分な挑戦でない場合、その名前に時間を通じて忠実であり続けることはさらに大きな挑戦となります。<\/P><\/P>では、なぜ新機能の命名とその名前に時間を通じて忠実であり続けることの課題について話すのでしょうか？ それは、この名前に忠実であり続ける課題がArcGISの少なくとも一つの機能にはあまりにも大きすぎたことが証明され、その状況への対応自体が私の意見では失敗となっているからです。<\/P><\/P>Boratがアメリカ文化について学ぶために全国をツアーしていた頃、EsriはArcGIS 9.2 (ArcGIS for Desktop Product Life Cycle Support Status<\/A>) をリリースしました。 彼がオレンジ帝国を通過するときにInstituteに立ち寄らなかったのは残念でした。それだけでチケット代の価値があったでしょう。 <\/EM>ArcGIS 9.2で導入された新機能の一つは、「一時的なフィーチャクラスとテーブルを書き込むためのin-memory workspace」であり、「特に中間（スクラッチ）データを書き込む際にモデルのパフォーマンスを大幅に向上させることができる」(What's New in ArcGIS 9.2<\/A>) とされていました。言うまでもなく、私は興味津々でした。<\/P><\/P>当時のスクリーンショットはありませんが、幸いにも私の所属機関のWayback Data CenterにはまだArcGIS 9.2（ビルド1324）がインストールされています！ 時計を巻き戻してin-memory workspaceの始まりを見てみましょう。<\/P><\/P>ArcMapを起動した後、一瞬コマンドラインに戸惑いました。 PythonウィンドウはArcGIS 9.4（別名ArcGIS 10.0）までコマンドラインに取って代わりませんでした（What's New in ArcGIS 9.4<\/SPAN> - リンクなし、PDFコピーも投稿できないと思います）。<\/>EM> 数分間コマンドラインに慣れ直した後、本題に入りました。 この投稿は機能名についてでありパフォーマンスについてではないので、新しいin_memory workspaceが本当にin-memoryなのかを見るためには多くの例は必要ありません。<\/>P><\/>P>私が思いつく最も簡単な例の一つは、in-memoryで新しいテーブルを作成することです:<\/>P><\/>P>それでは、目次内のSourceタブを見てみましょう:<\/>P><\/>P>そこにあります、新しいテーブルがGPInMemoryWorkspace内にあります。 同じテーブルをもう一度作成するとどうなるでしょうか:<\/>P><\/>P>ここまでは順調です。 テーブルが既に存在するためエラーになることは予想通りです。 in-memoryテーブルを削除しようとした後の目次も見てみましょう:<\/>P><\/>P>まだ順調です。 Deleteコマンドは機能し、in-memoryテーブルは消えました。<\/>P><\/>P>これ以上スクリーンショットで投稿を乱雑にしませんが、in-memoryフィーチャクラスの作成も上記テーブルの場合と同様でした。また、ArcToolboxを使用してin-memoryフィーチャクラスおよびテーブルを作成してもコマンドラインと同じ結果でした。<\/>P><\/>P>実際にデータを含む例として、米国州境界線を含むフィーチャクラスをArcMapに読み込みました。 in_memoryワークスペースが宣伝通り機能しているならば、単純なCopy Featuresコマンドでうまくいくはずです。<\/>P>さて、ご覧の通り、フィーチャーのコピーがin-memoryワークスペース内に読み込まれています。上記基本例は決定的なテストからは程遠いですが、それでもArcGIS 9.2以降ユーザーはArcMap作業中、中間データをin-memoryで保存できる能力を持っていることを示しています。全体として、この点についてマーケットロイドたちは正しかったと言わざるを得ません。このin_memory workspaceは、その設計範囲内では本当にin-memoryなのです。新機能命名という課題について言えば、Esriは'in_memory'で成功したと言えるでしょう。その名前は短く説明的であり、最も重要なのは正確だからです。今後問われる課題または挑戦は、新しいバージョンのArcGIS Desktopでさらに新しい機能が導入されても'in_memory'が元々の機能性に忠実であり続けられるかどうかということになります。
<\/P>
ソフトウェアアプリケーションで新機能に何と名付けるかを決める際には、比較的短くて比較的説明的な名前が通常は勝ちます。 本当に理にかなっています。誰がヘルプやスーパー・デコーダーリングを使って、その機能が何をするかしないかのアイデアを得たいと思うでしょうか。 しかし、短すぎたり説明的すぎたりすることにはリスクがあります。前者は重要な限定条件や細かい注意書きが省略されることが多く、前者と後者を組み合わせると通常、ユーザーは誤った理解、つまり機能が何をするかを知るのではなく推測してしまうという誤解に陥ります。 新機能に名前を付ける行為自体が十分な挑戦でない場合、その名前に時間を通じて忠実であり続けることはさらに大きな挑戦となります。<\/P>
では、なぜ新機能の命名とその名前に時間を通じて忠実であり続けることの課題について話すのでしょうか？ それは、この名前に忠実であり続ける課題がArcGISの少なくとも一つの機能にはあまりにも大きすぎたことが証明され、その状況への対応自体が私の意見では失敗となっているからです。<\/P>
Boratがアメリカ文化について学ぶために全国をツアーしていた頃、EsriはArcGIS 9.2 (
当時のスクリーンショットはありませんが、幸いにも私の所属機関のWayback Data CenterにはまだArcGIS 9.2（ビルド1324）がインストールされています！ 時計を巻き戻してin-memory workspaceの始まりを見てみましょう。<\/P>
ArcMapを起動した後、一瞬コマンドラインに戸惑いました。 PythonウィンドウはArcGIS 9.4（別名ArcGIS 10.0）までコマンドラインに取って代わりませんでした（What's New in ArcGIS 9.4<\/SPAN> - リンクなし、PDFコピーも投稿できないと思います）。<\/>EM> 数分間コマンドラインに慣れ直した後、本題に入りました。 この投稿は機能名についてでありパフォーマンスについてではないので、新しいin_memory workspaceが本当にin-memoryなのかを見るためには多くの例は必要ありません。<\/>P><\/>P>私が思いつく最も簡単な例の一つは、in-memoryで新しいテーブルを作成することです:<\/>P><\/>P>それでは、目次内のSourceタブを見てみましょう:<\/>P><\/>P>そこにあります、新しいテーブルがGPInMemoryWorkspace内にあります。 同じテーブルをもう一度作成するとどうなるでしょうか:<\/>P><\/>P>ここまでは順調です。 テーブルが既に存在するためエラーになることは予想通りです。 in-memoryテーブルを削除しようとした後の目次も見てみましょう:<\/>P><\/>P>まだ順調です。 Deleteコマンドは機能し、in-memoryテーブルは消えました。<\/>P><\/>P>これ以上スクリーンショットで投稿を乱雑にしませんが、in-memoryフィーチャクラスの作成も上記テーブルの場合と同様でした。また、ArcToolboxを使用してin-memoryフィーチャクラスおよびテーブルを作成してもコマンドラインと同じ結果でした。<\/>P><\/>P>実際にデータを含む例として、米国州境界線を含むフィーチャクラスをArcMapに読み込みました。 in_memoryワークスペースが宣伝通り機能しているならば、単純なCopy Featuresコマンドでうまくいくはずです。<\/>P>
さて、ご覧の通り、フィーチャーのコピーがin-memoryワークスペース内に読み込まれています。
上記基本例は決定的なテストからは程遠いですが、それでもArcGIS 9.2以降ユーザーはArcMap作業中、中間データをin-memoryで保存できる能力を持っていることを示しています。全体として、この点についてマーケットロイドたちは正しかったと言わざるを得ません。このin_memory workspaceは、その設計範囲内では本当にin-memoryなのです。
新機能命名という課題について言えば、Esriは'in_memory'で成功したと言えるでしょう。その名前は短く説明的であり、最も重要なのは正確だからです。今後問われる課題または挑戦は、新しいバージョンのArcGIS Desktopでさらに新しい機能が導入されても'in_memory'が元々の機能性に忠実であり続けられるかどうかということになります。
I have heard back from Esri Support and Esri Development. I will restrict comments on the first three parts in the series and post final comments with part four of the series: What's in a Name: When Known = Unknown .
I am quite certain in-memory workspaces are here to stay, and I am not advocating for their demise. The question or issue for me is whether in_memory really gets you in-memory, which it doesn't in all cases. When in_memory really means on-disk, the workspace isn't any faster than scratch on disk. The next two blog posts will get into specifics.
I sincerely hope in_memory workspaces are here to stay. Even if you can save only simple tables an feature classes in them, they have been extremely useful. I don't really mind whether they are truly in memory or somewhere else, as long as they are fast and don't leave a trace when deleted.
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
