前回のエントリで、「とにかくマイクロフォーマットを使うべし」という結論だったので、使ってみましょうね。

ご注意：Firefox に、Operator を入れてご覧になってください。そうしないと、全然面白くないです。

（.....多分、この通りに見に行くのではないかしら？）

---

ねえ、今度の土曜（6/28）宝塚見にいこ！

今の公演はねえ、

2008年6月28日 11時（14時くらいに終わります）
星組「スカーレット・ピンパーネル」 場所 宝塚大劇場

---

<p>ねえ、今度の土曜（6/28）宝塚見にいこ！</p>

<p>今の公演はねえ、</p>

<!-- hCalendar -->
<p class="vevent" id="hcalendar-星組「スカーレット・ピンパーネル」 ">
<a class="url" href="http://kageki.hankyu.co.jp/"><abbr class="dtstart" title="2008-06-28T11:00+09:00">
2008年6月28日 11時</abbr>（<abbr class="dtend" title="2008-06-28T14:10+09:00">14時くらいに終わります</abbr>）<br />
<span class="summary">星組「スカーレット・ピンパーネル」</span>
場所 <span class="location">
<!-- geo -->
<abbr class="geo" title="34.807214;135.346434">宝塚大劇場
</abbr></span></a>
</p>
<div class="description">今度はねえ、ブロードウェイミュージカルよ！</div>

<!-- tag -->
<div class="tags">Tags: <a rel="tag" href="http:
//www.technorati.jp/tag/%E5%AE%89%E8%98%AD%E3%81%91%E3%81%84">安蘭けい</a>
</div>

<p>あ、初めてだったのよね...じゃあ、勉強よ！</p>

<!-- xFolk -->
<ul>
<li><span class="xfolkentry">
<span class="description">宝塚リンク：
<a href="http://kageki.hankyu.co.jp/" class="taggedlink">宝塚歌劇団</a>
</span></span>
</li>
<li><span class="xfolkentry">
<span class="description">宝塚リンク：
<a href="http://www.nurs.or.jp/~sug/takara/kangeki/" class="taggedlink">私の宝塚評論ページ</a>
</span></span>
</li>
</ul>

<p>この間ねえ、主演の安蘭けいさんにご挨拶したのよ！ 名刺もらっちゃった！</p>

<!-- hCard -->
<div class="vcard" id="hcard-けい-安蘭">
<a href="http://kageki.hankyu.co.jp/star/star/hero.html" class="url fn">安蘭けい</a>
<div class="org">宝塚歌劇団</div>
<a href="mailto:aran@hankyu.co.jp"
class="email">aran@hankyu.co.jp</a>
<div class="adr">
<span style="display: none;" class="country-name">日本</span>
〒<span class="postal-code">665-0845</span>
<span class="region">兵庫県</span>
<span class="locality">宝塚市</span>
<span class="street-address">栄町１丁目１－５７</span>
</div><p>
TEL <span class="tel">0570-005-100</span></div>
</div>

６月１３日に例の「マイクロフォーマット」出版の関連企画として、原著者の Allsopp 氏の講演があったりとか、あるいはその翌日にも Allsopp 氏のセミナーがあったり...とかは、出席した方のブログの情報などを参照するといいでしょう....

• ネコゼ氏
• Forest.Kの徒然日記
• Hamashun.com

で、ですけども、Allsopp 氏が CSS のエキスパートでもある...というあたりからの話です。マイクロフォーマットとCSS って、「普及」という面では本質的に似た側面があるのと、その同じ本質が時代によってまったく正反対の現われをしつつあるなあ...ということについてのちょっとした感慨です。

私はまだ20世紀だった頃から、「コンテンツとデザインを分離するCSSという技術はものすごく大事だ！」といい続けてきました（結構自慢）。しかし、当時（IE4/NN4世代）では、

CSS なんてバグだらけだし、ブラウザ互換性もないし、難しいし、何でこんなん使わないといけないんだ！

というような風潮がフツーでしたね（遠い目...）。それがブログの普及と共に、

コンテンツとデザインが強制的に分離される

のが当たり前になったことで、一気に普及していったのを目の当たりにしたわけです.....（そこらへんの忸怩とした感情を証言するよいページがあります）

勿論、CSS 普及を阻んだ最大の障害は、MS と Netscape とが、規格をめぐって争い、MS の CSS と Netscape の JSS(JavaScript Style Sheet って憶えてる？)と一歩も譲らなかった...ところが、CSS が標準として採用されて、遅れをとった Netscape の CSS 対応が場当たり的になって、互換性が薄くなっていた...というあたりにある、というのは憶えている方もいることでしょう。

ブラウザ ＝ 企業の重要な戦略商品

だった時代の意地の張り合いの結果ですよね....

実は Allsopp 氏の進める CSS3 の普及....というのは、まだW3Cの正式の規格にさえなっていないものです。しかし、それでも FireFox や Opera はすでに一部 CSS3 の規格を先取りして実装していたりするわけです。

要するに言いたいこと、はですね、「世論」と「規格」と「実装」の関係が、20世紀と大きく変わってきた、ということなのです。

20世紀：

「規格」はあっても、「世論」に反して「実装」は進まない

21世紀：

まだ「規格」がキッチリ整備されていなくても、「実装」は進み、「世論」はそれを歓迎するかもしれない.....

勿論この現象の原因というのはオープンソースです。ある規格（候補でもＯＫ）を「面白い！」と思うプログラマが存在し、それを実装するオープンソースプロジェクトを立ち上げたら、賛同するプログラマが集まって、正式な規格以前に実装が出来てしまい、正式な規格として採用される以前に世論がそれを受け入れる....というのが、別に非現実的な話ではなくなってきているのですね。つまり、

業界をリードするための神経戦としての規格の攻防

というはなはだ非生産的な企業の「戦略」がもはや意味を持たなくなってきている...ということでもあるわけです。その結果、

規格の良い実装がないのは、その規格が知られておらず、使う人がいないから
                                   ⇔
使う人がいないのは、まともな実装がないから

という「卵が先か、ニワトリが先か」のパラドクスとようやく手を切れるのでは...ということでしょう！？

ですから、マイクロフォーマットを普及させるためには、ただただひたすら、それを扱うサービスとツールを作り、マイクロフォーマットを使ったマークアップを実践すること....で済むわけです。問題は単純、だといいな！

そして、それらを「いつか使える日が来るといいね」ではなくて「もう、ガンガン使っちゃおうぜ！」というのが、John Allsopp氏が繰り返し言ってたことだと思うんですよ。

CSS3を先行実装しても、古いブラウザに悪影響は及ぼさない。最新のブラウザに向けて異なる効果を与えても、情報は失われない。より良い視覚を提供できるにこしたことはないじゃない……と。

（ネコゼ氏のブログより）

ちなみに、CSS3 というのは、実はとっても日本語メリットの多い規格のようです....「正しい禁則」とか、「原稿用紙レイアウト」とか、「独自機能」としてしか実装されなかったことが、ちゃんとした規格になるわけです...

面白いページを見つけました。

知力勝負！ goto文類似構文を全て封じた構造化パズル・プログラミング!!

.....要するにですね、いわゆる「構造化プログラミング」というものを、マジメに受け止めすぎると、本当に「パズル」としか言いようのない、直感的理解を拒むような難解コードに化けてしまう...という実は当たり前のことを、このページはホントは主張しているわけです（break じゃなくて、ミスしやすいフラグ管理をすることを考えたらぞっとしますよ....)。

本当に恐ろしいことはですね、今でも break や continue を使うのをためらうような、「構造化原理主義者」みたいなコードがあったりすることです。言い換えると、このパズルで禁止されていること、

1. 1. ループを抜ける break の禁止（switch 文の中は当然ＯＫ）
2. 2. continue 禁止
3. 3. return は最後に１個だけ

は、イマのプログラムでは全然守るべきことではないと言っていいわけです。というか、Java に関して言えば、Java 自体の標準ライブラリコードでも見てみれば一目瞭然で、そのような不自然な「構造化コード規約」はまったく採用されていないわけですし、また広く使われているオープンソースのコードでも同様です。なぜか日本の業界では、そういう時代遅れの規約感覚が残っている（教育現場が遅れてるの？）のが、私は不思議で仕方がないのですが....

ですからこのパズルは一種の「系統的脱感作」として役に立つのでは...なんて面白く感じているのですね。実際、このように徹底した「構造化規約」は、タダの知的遊戯に過ぎません。

ちなみに、悪の権化であるところの goto 文ですけども、これだってキレイな構造の中で使うやり方がないわけではないのです.....

イマの職場で、すごく違和感のあるお話です。

crontab は、「クロンタブ」？それとも「クーロンタブ」？

というお気楽ネタです（参考）。まあ、仕事で使う難読系単語の読み方の話ですね。私は「クロン」と伸ばさない派です。だってえ、chronicle とかそういう語源でしょ、あれ（発音しない字を落とす...というのは「昔のハッカー流超合理主義」かな？）。クーロンと伸ばすと、クーロン力（こっちはcoulomb）が働くみたいでイヤじゃないですか（苦笑）。

まあ、そういう読み方の謎...というと、要するに「略語の略し方」が原因で、「何と発音していいのかしら...」と悩むケースが多いのではと思います。古典的なのは、

strcat(3)

ストリキャット or ストラキャット

malloc(3)

マロック or エムアロック

stdio.h

スタンダードアイオードットエッチ or スタッディオエッチ

といったＣ言語関数などの読みの話がありますし、Java 系だと、例の難読系ライブラリ名が、普及したときに「読み方の大困惑」を引き起こした...のは憶えのある人も多いのでは。

xerces

ザーシーズ or ザーセズ or ザーシス....など「ー」入る／入らない、濁る／濁らない、「シ」／「セ」の組み合わせが、すべてありうるかも....理屈上８通り？

確か落語じゃなかったっけ....

昔、弘法大師空海が修行した唐のお寺「青龍寺」を「せいりゅうじ」と呼ぶのか「しょうりゅうじ」と呼ぶのかで、お坊さんたちの間で大論争が起きました。「じゃあ現地に行って、何と呼ばれているか調べて決着しようじゃないか」と中国に僧を派遣することになりました。僧が現地（長安・今の西安です）の住民に聞くと「私ら昔からチンロンスーと読んでますけども...」と答えました。

ちゃん、ちゃん？

今まで何度も紹介している「マイクロフォーマット～Webページをより便利にする最新マークアップテクニック～」ですが、いよいよ７月２３日に発売だそうです。

いよいよ...ですが、「満を持して」くらいの感じかな。個人的にはもう少し早く出てても良かったかなぁ...という気もします。最近結構翻訳プロジェクトの方が充実してきつつあるのもあって、「細かい情報を得る」という点では、少し遅れを取ってる気がしないでもないです。しかし、「本で出ること」というのは大変重要にも思います...

というのは、「どうすれば使えるか」ということを書籍によって学ぶ、ということは今時インターネットの上の情報にどうしても負けるわけです。やはり書籍のイイところ、というのは、

1. 1. 単一の著者によって書かれているので、「その著者が把握している全体像」みたいなものが理解しやすい。
2. 2. 当初から関わっている著者なので、「なぜそれが出てきたのか」という哲学に関する部分が期待できる....
3. 3. まだアイデアに過ぎないものであっても、その意味を理解しやすい

というあたりが重要ではないかと思います。「マイクロフォーマット」って意外に「○○でこう使われている」というタイプの情報が多いので、枝葉の部分での理解はそれなりに進んでいるのでしょうけども、私が見るところマイクロフォーマットは一般的な意味での「セマンティック・ウェブ（まあ、批判も多い概念ですが）」の「とりあえずのイマの解」という重要な哲学的な意味を持つものでは...と感じる面があるからです。

「なぜマイクロフォーマットを使うのか」という（単なる流行ではなくて）実践的に重要な問題の手がかりには、やはり「実装ではなくて思想の普及」が決め手になるのではないのでしょうか。去年年末の「RESTful Web サービス」でも、

REST=SOAPを使わずすべてURLに畳み込むアクセスの仕方

という「作り方の技法」ではなくて、REST のウラにある考え方の紹介がキッチリしていたからこそ、あれほど評判になったように、

イマの技術書籍のあり方

みたいな部分での期待...みたいなものを抱くって、過剰期待過ぎるかなぁ？

 

そういえば、Java でも Java5 からは可変長引数を使えます。

とはいえこれは Object[] 引数の甘口文法に過ぎず、可変長引数を示す変数は

Varg( String... args ) {
  System.out.println( "args:" + args.getClass().getName() );
  System.out.println( "args.length=" + args.length );
  System.out.printf( "%s %s %s\n", (Object[])args );
}

のように、args は「現実には Stirng配列」というのが見え見えなかたちで書くことが可能です(例外はSystem.out.printf の引数でキャストしないと警告されるくらい)。Ｃ言語の可変長引数みたいに、

printf フォーマットの %書式指定と引数とに整合性がないと、スタック解釈を間違えてトンでもない結果を出しちゃう....

というようなものではないわけです。まあ、Ｃの可変長引数は、スタックに詰まれた引数を「何かの手がかりをもとに」解釈して、適切にスタックから拾い出す...という原始的な仕掛けなので、スタックをちゃんと理解してないと本当はうまく使えない、というものだったりしたわけですが..... Java ではたかが「Object配列」に過ぎませんので、そういう危険性とか解釈ミスとかは、あったとしてもきっちり例外にしてくれます。ですから、

黙っていい加減な結果を返すCの可変長引数

よりも安全なことは言うまでもないです。

他の言語でも「可変長引数」という機能があるケースもありますが、よくよく見てみると、言語によって「可変長引数とは何か？」というのは、きわめてヴァラエティに富んでます。

たとえば、Perl だと、すべての引数は「それ自身可変長引数(というか配列である)」の @_ をパターンマッチして、仮引数に具体的な値をセットします。ですから、Perl だと実は

可変長が基本で、固定長になるのは単に
my($a,$b) = @_
とするから

というのが真相です。可変長をそのまま可変長として扱うのならば、

sub count {
  my(@a) = @_;
  if( @a == 0 ) { # 引数個数がゼロ
    return 0;
  } else {
    # 最初の引数を除外して再帰呼び出し
    return 1 + count( @a[1..$#a] );
  }
}

print count( "this", "is", "a", "pen" ) . "\n";
print count( "this" ) . "\n";
print count() . "\n";

のように、配列の @_ をそのまま配列で受けるだけでOKです。

あと、Lisp  系言語でも可変長引数、というのはあります。Lisp ですからこっちは基本単位が配列ではなくて、リストなのですが、リストとしては「要素がいくつあるか判らないリスト」を「ドッティド・ペア（リスト）」と呼ばれる一ひねりのあるデータで受けます。まあ「一ひねり」と言っても原理的には単純なのですが...

一般にリストの最後の要素は「空リスト(NIL)」でなくてはならないし、リストの途中で見る場合（言い替えると「リストを対象とする任意の cdr」が返すもの）は、基本的にリストでないことはないはずです。しかし、最後の要素をリストでない値や変数シンボルにすることもできない相談ではないです。勿論そこでリストは終り、その後に更に何かデータを追加することはできなくなります。これを一般的なリストと区別して、「.」を置くことで

(1 2 3 . x)

と書くことができます。今 x は変数ですから、この表現は

(append '(1 2 3) x)

と同じことになり、x が (4 5) ならば言うまでもなく

(1 2 3 4 5)

を示しますし、x  が () （空リスト）ならば、(1 2 3) を示します。この x  という末尾の変数が、

いくつ要素があるか判らないが、後続する要素である

ということを、リストとして表現することになるわけです(何か言いくるめているみたいですが....判ったかな？)。

だから、関数を定義するときに、

(define (varg a . b)

というように、引数が一個以上あり、a が最初の引数を、 b がそれ以降の(いくつあるか不明な)引数をそれぞれ示して、可変長引数が実現できることになるわけです。ちょっとパズルみたいで面白いでしょう？

そういう具合に、可変長引数って言語によって考え方がすごく違う面白さがあったりします。どうです！

 

結構最近、社内で「集計関連は私の担当」みたいな格好になっています....というのは、私が「Composite 使い」だから、というのが理由のようです。

Composite パターンって確かに好きです。

1. 1. あらかじめ集計の項目の枠組みを作る。
2. 2. そこに集計対象を流し込こむ。
3. 3. 表示用の順番で、集計行を得る。

という３ステップで整理できますから、一度コレに慣れちゃうとほんとに手放せないデザパタの一つです。また、「枠組み作り」と「集計対象」が手順的にキッチリ分離できますから、ＤＢのクエリも最適化しやすいですしね。

小計用の集計変数と、総計用の集計変数を、集計が必要な項目の数だけ用意して、ループで回して....

というような処理とはおさらばしたいところでしょ！

で、ですが、私の常套手段で、このような Composite のフレームに対して、

public void 何か好きなことして();

というようなメソッドを定義する、というのが今回のネタです。

要するに、「枠組みを作った後」、あるいは「集計対象を流し込んだ後」に、枠組み構造を渡り歩いて（traverse）、補足的な調整をしたい...ということはよくあります。枠組みを作りながら、あるいは、集計対象を流し込みながらだと、「できない」「やりづらい」処理を、あとでまとめて「しなさい」というメソッドです。

とはいえ、Composite のフレームと、実際にその枝葉となるオブジェクトは分離した方がいいので、そういうケースだと

何かして欲しいんだけども、「何」をして欲しいのか、設計段階では特定できない！

という状況に陥ります。具体的なかたちとしては、フレームの側では

// in CompositeFrame(Composite の枠組み)
/** 自身が保持する集計情報とか */
private CompositeItem item;
/** 子要素 */
private List<CompsoiteFrame> childs;
/** 何かしなさい */
public CompositeItem traverse() {
  for( CompositeFrame child : childs ) {
    this.item.onTraverse( child.fire(o) );
  }
  return this.item;
}

 

// in CompositeItem
// 集計情報側のコールバック
public void onTraverse( CompsiteItem child );

という感じで書けば、集計情報などの個別に変わる要素を保持するクラスである CompositeItem（の派生クラス）では、単純に

1. 1. 自身の子要素たちの、孫以下の要素ついての onFire() の処理が完全に済んだ状態で、
2. 2. 自身の子要素が引数に渡って、子要素の数だけ onFire() が呼ばれる。

というかたちで実装することができます（再帰、大丈夫？）。この実装が「自分のことだけを考えればＯＫ」なので、一番使いやすいように思います。

で...ですが、このインターフェイスは少しだけ問題があります。

「集計枠組みを構築した後」と「集計要素を流し込んだ後」で、２回Compsite フレームを渡り歩きたいのだけどもね。

というときに、最初の traverse() と２回目の traverse() が呼び出し上区別できないことになります.....

勿論これは、最初から、

public CompositeItem traverse(Object o);
public void onTraverse( Object o, CompsiteItem child );

と、「あまり意味がないかもしれない引数」を渡しておくのが柔軟なやり方です。単純に Object 型引数ですから、それこそ渡そうと思えば何だって渡りますし、それを「どう解釈するか」は onFire() の実装次第です。引数を「呼び出しの区別」として扱ってもいいし、何かの追加情報として扱ってもいいのです....このように、

引数として定義するけども、使い方をまったく決めてなくて、実装クラスで好きなように使えばいい

という引数の使い方って便利なんですよね～～～

まあ、これはその昔の Xツールキット・プログラミングの常套手段(CallbackData)で憶えたのですが、「どう使うかは実装クラスでお任せ」な Object 型引数、って意外にデザパタ、かもしれませんね！

有名な話かなあ...とも思うのですが、

魔法の数字＝７（あるいは７±２）

というのをご存知でしょうか？これは心理学で（→引用元）

「魔法の数７±２：我々の情報処理能力の幾つかの限界」。この研究では、ランダムな数字の並びを被験者に記憶させ、後に正確に反復できるかを見ることで、どの程度の情報量を人は一度に記憶できるのかを繰り返し試験した。その結果、このマジックナンバーが判明するわけだが....

という結果があって、「人間が特に意識せずに、間違わずに処理できる最大の数が７±２だ」という結論を一般に導くものです。ですから、これを受けて、よくコーディング規約で

引数の数の最大は７

という規約が採用されることになります。

とはいえ....結構実際のプログラムでは、そうも言ってられないこともあります。勿論、

引数があまりに増えちゃったから、それをまとめる情報渡しの構造体（とかクラス）を作って、間違えにくくしよう....

というリファクタリングをするのはとても良いことです。

で....ですが、「現実に最大どのくらいの引数が渡ってるの？？」というのは、また　別の問題です。勿論

引数の数の最大値

が言語（orコンパイラ実装）によってはないわけでもないでしょう。私が知ってる範囲だと、Ｃ言語規格の「翻訳限界（この限界を超えたらコンパイルできなくても、そのコンパイラは「規格に合致している」と主張できる最大値）」は、３１個です。じゃあ、Java だとどうだろう...と調べてみましたが、記述が見つからないようです。ひょっとして無制限？と思って、引数 200 個のメソッドを定義してみましたが、全然コンパイルも実行も問題ありません。まあ引数200個で問題がないのならば、現実的に「無制限」と捉えてよいでしょう。

では、現実的に...で考えると、

Java の標準ライブラリではどういう引数の数の分布をしているか？

が参考になるのでは、と思います。「Java: 利用可能なクラスを一覧する」で紹介したやり方を基に勘定してみました。範囲は Java5 の java.*, javax.* パッケージの public なクラスの public なメソッド（とコンストラクタ）で見るのが公平というものでしょう。

結果は、

数	メソッド (%)	コンストラクタ(%)
0	8215(41.57)	844(28.83)
1	7591(38.41)	1030(35.19)
2	2220(11.23)	556(19.00)
3	946(4.79)	211(7.21)
4	322(1.63)	131(4.48)
5	162(0.82)	63(2.15)
6	206(1.04)	45(1.54)
7	54(0.27)	19(0.65)
8	27(0.14)	10(0.34)
9	4(0.02)	6(0.20)
10	7(0.04)	2(0.07)
11	5(0.03)	6(0.20)
12	2(0.01)	0(0)

となって、最大引数１２個のメソッドがあり、コンストラクタの場合は１１個が最大になります。で...やはり６個を境にして、それ以降はぐっと減ります。やはり「魔法」の伝説は事実のようですね。

ちなみに栄えある最大引数のメソッドは、

javax.swing.plaf.synth.SynthGraphicsUtils#layoutText
javax.swing.SwingUtilities#layoutCompoundLabel

で１２個も引数があります....まあ、ＧＵＩ関連はどうしても引数が多くなる傾向がありますよね。ちなみに、「public クラスの public メソッド」という制限を外すと、

javax.swing.plaf.synth.SynthMenuItemUI#layoutMenuItem

がなんと 22 個！の強烈な数を取ります。お姿は、

    private static String layoutMenuItem(
        SynthContext context,
        FontMetrics fm,
        SynthContext accContext,
        String text,
        FontMetrics fmAccel,
        String acceleratorText,
        Icon icon,
        Icon checkIcon,
        Icon arrowIcon,
        int verticalAlignment,
        int horizontalAlignment,
        int verticalTextPosition,
        int horizontalTextPosition,
        Rectangle viewRect,
        Rectangle iconRect,
        Rectangle textRect,
        Rectangle acceleratorRect,
        Rectangle checkIconRect,
        Rectangle arrowIconRect,
        int textIconGap,
        int menuItemGap, boolean useCheckAndArrow
        )
    {

という強烈なものです....呼び出しも、

        String text = layoutMenuItem(context, fm, accContext,
            b.getText(), accFM, acceleratorText, b.getIcon(),
            checkIcon, arrowIcon,
            b.getVerticalAlignment(), b.getHorizontalAlignment(),
            b.getVerticalTextPosition(), 
            b.getHorizontalTextPosition(),
            viewRect, iconRect, textRect, acceleratorRect,
            checkIconRect, arrowIconRect,
            b.getText() == null ? 0 : defaultTextIconGap,
            defaultTextIconGap, useCheckAndArrow
        );

と Java 離れしてますね！

さて仕事からのネタ（ボヤキ入ってます）です。今他人の書いたプログラムの修正をしているのですが、こういうシグチュアのメソッドが頻出していて参ってます。

対象_操作_オプション();

....このタイプのメソッドが延々と続いているのです。これ、

操作(対象,  オプション);

じゃないの......というのが素直な印象です。まあこのクラスは Hibernate のエンティティのクラス（ＤＢテーブルと結びついている）なので、「コレ」より細かい内部構造が用意されている、ということはなくて、「末端のクラス」になりますから、より抽象化するのならば「自前で内部構造を用意する必要がある」ことになります。

勿論、無引数タイプをする理由...というのは、

対象（インスタンス変数）の変数型が対象によって違う

あたりなのでしょうが、これは引数型のポリモルフィズムで解決すべきです。要するに、

モノ（クラス）はモノなので、「具体的なモノ」としての操作を書かなくてはならない

という妙な意識があって、こういうインターフェイスになってしまっているような気がします。

実は、プログラミング言語の最大の武器である、「抽象化」の一番最初のステップは、

（グローバル変数渡しの）サブルーチンではなくて、（スタック引数渡しの）関数で

という進歩なのです。実は私が一番最初に触れたプログラミング言語は、

N88Basic（懐かしい...）

だったので、一番最初に「関数による抽象化」を理解したときには少しカルチャーショックを受けたくらいです....勿論 Java はサブルーチンを「関数」のかたちで表現する言語であって、COBOL ではないのです。

私って梅雨時ヨワいんです....どうも心理的に落ち込みやすいんですね。で、その対策。ちょっと衝動買いです....買ったのはソフトです。

SONAR 6 XL

というわけです。あ、これWindows の人気作曲ソフト（の型落ち廉価版）です。最近ご無沙汰してましたけども、趣味で作曲とかした時期もありますので、落ち込んでる自分に「喝入れ」で「趣味復活」という感じでしょうか。

昔....というと、シンセ買ってシーケンサ買って、ドンカマ買って、タスカム買って、あとは音源にエフェクター？というくらいに出費の嵩む趣味ではあるのですが、最近ではそこらへん「全部ソフトになっちゃって」います。ですからコンピュータ本体以外に、

• [必須] オールインワンのソフト（SONAR とか Cubase とか....）
• [オプション] 入力用キーボード（勿論109とか101なキーボードではなく、61とか76なキーボード。コンパクトがよければ 25 とか 49 でも...）
• [オプション] サウンドインターフェイス（サウンドカードとは別物）

の３つが揃えば、とりあえず不自由のない作曲～ＣＤ焼き（譜面印刷もできます....）までの環境が揃うことになります。

まあ、それでも Roland がバックの SONAR を選んだ...というのは、やはりブランド、というのはないわけではないです。考えてみれば、ずっと安い作曲ソフトとかあるわけですし、作曲ソフトの操作性とか「できること」というのは、安い（とかフリーとか）作曲ソフトと、ブランドソフトとの間でほとんど違いがないのです。違う...のは、要するに、

コンピュータの上で動くシンセ（ソフトシンセ）の音の種類と音のクオリティが、やはりブランドはブランドだけの価値がある....

ということになるわけです。ですから、ほとんど

イイ音の出る環境を作るために、ブランド品を選んだ

ということになります（まあ、ワリと Roland 贔屓な方でもありますし）。としてみると、

Ａ（アルゴリズム）＋Ｄ（データ）＝Ｐ（プログラム）

ではなくて、

Ａ（アルゴリズム）＋Ｄ（音色データ）＝Price

かもしれません.....（ごめん、この洒落判った？）

これは最初から書こう、と思ってたことではなくて、偶然最近、私の「書法」について同僚が「Unix風(Unixism)だよね...」と感想を漏らしたことからネタにしよう、というものです。とはいえ「プログラマ文章読本」のテーマである、「読みやすく、理解しやすいプログラムのためのTips」というテーマともマッチする話なので、この枠で紹介するのが適切でしょう。

というのは、私が仕事を始めたのはMS-DOSでしたけども、本当にプログラミングのあれこれについて、深く理解した...と思うのは、やはり Linux でいろいろと書くようになってからです。ですから「UNIXならではのプログラミングの習慣」というのが身に染みついていて、それを特に意識せずに今でも仕事で実践しているのですが、これを同僚たちが見てある意味「感心して」いたみたいなのです。じゃあ、どういう習慣かというと、

1. 1. 設定ファイルには、「どんなオプションが設定でき、そのオプションでどんな値を取ることができるのか」をきっちり記述したコメントが大量に入っている。

というのがまず１番目の Unixism です。Unix は「テキスト文化」が徹底していますので、

設定ファイルは昔からテキストであり、どう設定するか懇切丁寧に記述したコメントが入っている

というのがアタリマエでした。ですから、私もその調子で設定ファイルに細かくコメントを書くことを、自然に憶えて実践していたわけです。これ自分で言うのも何ですが、自分で書いたプログラムでも「何が設定可能か」の詳細は忘れちゃうもので、コメントが入っていたら思い出すきっかけが出来ます。ましてや他人さんが「設定しよう」という時にこれがあるのとないのとでは大違いです....「あ、設定ファイルのコメントを見て設定してね！」の一言で済んでしまいました！

2. 2. コマンドラインから使うツールの場合、何も引数を指定しなくて起動したら、どういう引数が可能かを示す Usage が表示される。

....これは Unix の多くのコマンドで（結果的に）実装されているやり方です。勿論、引数が何もなければ「標準入力から読んで、標準出力にデフォルトオプションで出す」という動作が正確なのですが、どうだとしても「引数なし」で起動したときに「取り返しのつかない更新動作は絶対しない」というのが暗黙の絶対ルールとしてあります。ですから、一般に「Unix コマンドが何をするのか正確に判らなければ、とりあえず引数なしで叩いてみる」というのは安全なのです（例外がないとは言いませんがね）。

勿論、多くのコマンドで（意図的に）実装されているのは、

-h　または --help オプションで「どんなオプションが使えるか」を表示する usage を出す

です。とはいえ、現実的には「存在しないオプション(-で始まる）が与えられた時も usage を出す」で実装されることが多いですから、仕様は実は逆で「-h, --help を特別にハンドルするコードはなく、デフォルトの usage 表示に落ちる」というかたちで書かれていることも多いでしょう。

私はこれも実践しています。ですから、引数なしで実際の処理は走らずに、usage を表示します。まったく Unix 流です。

.....とはいえ、この２つの Unixism で具体的に記述される内容は、この「プログラミング文章読本」の趣旨から言うと、完全に「仕様」であり、ですから私は実はそのプログラムを書き始める時に、実際には「設定ファイルから」「Usage から」書き出しているくらいのものです。やはり「プログラムが何をするのか」はあらかじめ「書いてある」ほうがずっと処理をイメージしやすいのです。勿論、プログラムを書きながら、「新しいオプションを入れよう」「意外な制限があるので、その旨をコメントしておこう」と、設定ファイルや Usage に手を入れながらプログラムが書かれていくことになります....

ですから、設定ファイルや Usage はけっして「事後的に作るもの」ではなくて、プログラムを書きながら一緒に作っていくものなのです....仕事ですとプログラミングと言っても「Unix の文化」は直接に関係しない、のが一般的ですが、こういう「好影響を与える側面」というのはあるのです。奥が深い、でしょ！

ちなみにここでは主題と外れるので、特に言わなかった３点目の Unixism は、「プログラムは必ずリターンステータスを返す。正常終了なら 0、エラーならば 1」です。Java だったら、プログラムの最後で System.exit(0) で終わりましょう。Unix パイプラインで使えるようになるかもしれませんよ。