ショウケースとしてのサンプルについて -「ユーザさん/開発者にとって」シリーズその2

今回はサンプルはどういう意味を持つのか、を書いてみたいと思います。
サンプルと一口に言ってもその目的は大きく2つに分けられます。
ひとつは機能を紹介するショウケース、もうひとつはベストプラクティスを紹介するサンプルアプリケーションです。
前者はミクロな視点で開発者にアプローチし、後者はマクロな視点でのアプローチともいえます。

今回は前者のショウケースとしてのサンプルについてです。
ショウケースとしてのサンプルはそれなりにディティールで紹介する必要があります。

たとえば、必須バリデーションについてのサンプルがあったとしましょう。
それは一番ノーマルな使い方を紹介するサンプルがあったとして、それだけでユーザさんは満足するでしょうか？
ユーザさんはきっと、「必須バリデーションをカスタマイズしたいときはどうするんだろう？」
「メッセージをカスタムに変えたいときはどうするんだろう？」といろいろ思い悩むことでしょう。
こういう事はある程度想定できます。
それなのであれば、出来るだけディティールでサンプルを作ることで機能を網羅的にあらかじめ紹介するほうがよいです。
なかなか全部のサンプルを網羅的には難しいものなんですが、できるだけ現実にあるような例はディティールで
紹介していくべきです。またショウケースは各機能ごとに閉じているべきです。なるべく外部リソースにたよらず
独立した存在のほうが、あとあとレバレッジが効きます。
で、ショウケースは機能が増加してくるとややもすると一覧にしても検索しにくくなってしまうので、検索容易性は
考えていくべきなんでしょうね。

開発者にとっては、実際に作ってみた機能のお試しの場としてショウケースは格好の場です。
実際に作ってみて、自分の理想のゴールと現実の使い勝手との差を吸収するための「自己フィードバックのための仕組み」で
あるといえます。またショウケースのサンプルをそのまま自動ITに組み込むことが出来れば、それが回帰テストにもなります。
この辺は仕組みありきの部分もありますが、T2はそういうことが出来るようにします。

ところで、ショウケースのサンプルってもっと誰でもコミットできたらいいのになと考えたことはありませんか？
おいらはまさにそう考えていて、なんかそういう仕組みを作れないものかと思ってます。
誰でもフリーにコミットできるサンプル集（バグの確認サンプルでもよい）のようなものが存在すれば、もっといいのかなと思ってます。

で、まとめると、ショウケースで必要なのはミクロ視点です。ある機能に特化したサンプルであればあるほどよい、
そのように考えています。

次回はベストプラクティスとしてのサンプル、サンプルアプリケーションの意義についてエントリしてみたいと思います。

P.S.親切なフレームワークでは、サンプルを動かして、どんなソースなのかなと見たいときに「View Source」みたいな
リンクをクリックするとそのサンプルのコードが見れたりします。こういう機能もショウケースとしてはあるとうれしいだろうなあと
感じています。また、サンプルをダウンロードしてWebコンテナ上に配備する人だけにショウケースのターゲットを
絞るのではなく、軽く動いているのをみたいよという方にも何か手段があると思っています。