日々の破片

_ 子供とゲーム

ポケモン探検隊が欲しいとか言い出すのでどうしようかちょっと迷ったが、とりあえずオモチャ売り場に行った。数日前、八潮のジャスコでのことだ。

見ると赤と青があって、片方はGBA用で片方はDS用。どう考えたってDS用のほうがおもしろいだろう。

ポケモン不思議のダンジョン 青の救助隊(-)

今買え、すぐ買えとうるさいが良くみたら取り寄せになっている。

だったら、アマゾンで買うことにする。それはそれとして本体はちょっと迷ったが新たに買ってやることにした。で、色はどれが良いか聞いたら白か黒だと言う意外性。青にしろといったらイヤだと言う。ピンクはどうだと聞いたらもうあるじゃんと言う（でもそれはオレのだ）。じゃあ黒と白どっちが良いと聞いたらちょっと逡巡した後に白を選んだ。確かにボタンの部分がきれいだ（アマゾンの売り上げランキングの結果だと、これを書いているタイミングだとシルバー10位がトップで以下、青が23位、白30位、黒51位、ピンク312位、赤がダントツの不人気で1278位。オレの選んだピンクはブービー賞で、子供は中庸）。

ニンテンドーDS ピュアホワイト【メーカー生産終了】(未定)

で、家に帰るとすぐにアマゾン、アマゾンと連呼するけど、どうせ買うなら寄付でもするかと日記サイトからアフィリエイトを探してそこ経由でアマゾンへ。最後の発注ボタンをクリックするまで監視してるのにはちょっと閉口した。で、夜になって誰かが玄関のチャイムを慣らしたら、「わーい」と叫びながら玄関へ向かうから不思議に思ったら、子供だ、5時間でアマゾンから送られてくると思ったらしい。配送ってのはそんなもんじゃないと教えてやったり。

で、ようやく届いた。これで2台目だ。というわけで、マリオカートの対戦モードを試してみることにする。1つしか無いから無理だと勝手に抗議するので、こいつは1つで遊べるはずだ、と教えてやる。

マリオカートDS(-)

対戦モードだとWiFi設定がいらないってことはアドホック通信なのか、とかいろいろ知る。

どうも、MACアドレスの記載がどこにもないと思ったら、ゲームのWiFi設定の中にあるってことも始めてわかった（というか、マリオカート自体、買っただけでこれまで開けていなかったからだ）。

ダウンロードは結構、早い。うまくできてるわ。最初、待ち状態に正しくさせなかったものでダウンロードが始まらなかったのだが、その時、なんかいろいろ向きを変えてるから、どうもIRを使ったゲーム機を友達の家かなにかで見たのかな、とか思ったり。で、やっと待ち受けにできたと思ったら、あっというまに認識してダウンロードが始まり、終わった。

で最初レースをしたらへたくそで驚いた。

次に、風船割りゲームをしてみた。ら、うまくて驚いた。

どうも、COMプレイヤーがいないとうまいみたいだ（つまりオレがへただということか？）。

で、再度レースに挑戦で、COMプレイヤーを無しにしたら、なんかこっちの独走状態。やっぱりへたみたいだ。

というわけで風船割りゲームを死ぬほどやらされた。

うまくできてるな、と思ったのはマリオカート1本をシェアするとキャラクターを選択できない点だ。それでももちろん遊べるのだが（特に風船割りだとまったく問題ない）レースはもしかしたらカートを選択できないのがきいてくるかも知れなかったりするから、そのへんがソフト購入の動機になるのかも知れない。特に、DSを持っている友達の家にDSとカートを持って行ってマルチプレイをするというシナリオだと、その友達もカートを購入したくなったりするのではないだろうか。多分、どうして購入しましたかアンケートみたいなものをやっているだろうから、マルチプレイモードによるプロモーション力みたいな統計は出しているとは思うが、興味があるところ（逆にマルチプレイができるから、仲間で誰かが1つ買っていればOKと思うという可能性もあるわけだし）。

_ ソースコードの文書性

文書性か、変な言葉だが他にうまい言い方が見当たらないのでそう呼ぶことにするが、はぶさんは精力的かつ誠実だなと読みながら、なぜオレは基本的には内製フレームワークを推するのかをつらつら考えた。ちょうどJW2月号を読んだというのもあるが。

ビジネス的な目線からの戦略的な選択ってのとそこから生まれる言質はもちろんあるわけだがそういったことは置いておくとして（というのは長期――10年、20年というスパン――ではビジネス目線には意味がないと思うからだ。逆に言えば3年程度の寿命のWebアプリケーションとかだと別にビジネス目線でも良いと思うが、長期では技術目線でなければ危ない――逆に言うと長期を意識していない／できないものに基盤をおくのはどうかとは思う。2つ引用しているが、これは後者の側だ。自分の会社を持っている人が長期を意識するのは当然なのでここにはそっちは含まれない）、それはやはりソースコードの文書性が重要だと思うからだ。

技術的、ビジネス的に関わらず、固有の語彙というものが企業にくっついていることは知っている人は知っている。どこぞで話題になっていたが「改修」とかもそうだし、以前2chのIスレで見たが「小職」とかのメール用語もそうだし、「.」を「ドット」と読むか「ポツ」と読むか「ピリオド」と読むか「点」と読むかといったささやかなものまで。「D」を「デンマークのデー」とやるか「ドイツのディー」とやるかまで（デンマークだとそのままデーで、ドイツだと英字変換が一度かかるからディーになったり）、いろいろある。

ソースコードはそういう連綿たる固有の語彙の集積物と見なすことができる。つまり文書と同じ性格がある。コード標準なんてのは実はそういうものを、外部から入ってくるものに対して内部の語彙に合わさせる仕組みなのだから、本当は書物から取るのではなく、レガシーソースコードから抽出すべきものかも知れない。そのあたりで、いろいろな流派が出てくるのだ。別にコード標準を唱える人たちが0ベースで考えているなんてことはあるまい。例えばSunのJava標準の源流にK&Rを見ることはできるだろうし、仮に（ちょっと現状では考えられないが）FSFがJavaソースを作るようになったら例の妙なインデントを標準にしてくるだろう。実際にソースコードを単にコンパイラやインタプリタへの入力データと見なすのであれば、コード標準なんて無意味なわけで、人間が読むことを前提としているわけだ。であれば、語彙をその文化に染めるのは読みやすさを考えれば当然のことである。その選択により暗黙の前提（行間だな）を含めることができるからだ。

外部から来るソースコードはその意味で異質な語彙を持つ。

外部から持ってくるものには、交換可能性かまたは予測可能な長期的安定性が求められる。CPUの外部調達−OSの外部調達可能性、OSの外部調達−POSIX標準、Win32の勢力、仮想機械(Java、.NET)、DBMSの外部調達−SQL、言語の外部調達（実は微妙）、サーバの外部調達（CGI、J2EE）。

フレームワークはそのレベルでは枯れていないと思える。というのはハードルの置き方にもよるだろうが、どれだけの長期に渡って変更が無かったかについて見ればまだまだ未熟だからだ（Strutsは3年程度固まっているように見えるので、比較的安心できる）。

枯れていないということは、短期利用には結構なことだが、中期利用以上の場合、そのソースコードをこちらで引き受ける覚悟が必要になってくる。

語彙の異なるソースコードをすらすら読むことは実際にはそう簡単なことではないと思う。というか、外部から持ち込まれたソースと、内部で作られたソースでは読むときの覚悟が（観察していると）異なるように見える。

#パラメータが多過ぎるのでここまで。

追記：単純な結論＝しのごの言わずにソース嫁ということだ。読んで合わなきゃ捨て、合えば拾い（あくまでも長期的な運用を考える場合ということだけど）。