PHPプログラマ的に実用的かどうかはさておき、SIGUSR2で紹介されているFnクラスをPHP 5.3(今ならRC2か)とセットで使うと、以下のようなコードを動かすことができる。

<?php
require_once 'Fn.php';
 
$r = Fn::foldl(function ($accumulated, $next) {
        return $accumulated += $next;
    }, 100, array(1, 2, 3));
 
var_dump($r);  // => 106

面白いけれど、PHPプログラマの手には余るような気も。

• Mixins considered harmful/1
• Mixins considered harmful/2
• Mixins considered harmful/3
• Mixins considered harmful/4

以下、かんたんなまとめ。

• Mixinを使いすぎるとクラス階層が爆発して、1クラスに数百メソッドなんて状況が頻発する
  • IDEのキーワード補完や、自動生成したAPIドキュメントが役立たずになる
• Mixinはフレームワーク作成者にとっては便利
  • 作成者はクラスの階層・関係が頭に入っているから
• Mixinはフレームワーク利用者には不便
  • フレームワークのバグや挙動を調べようと深みに入ると処理を追い切れなくなる
• 比較的小規模で品質が安定したライブラリで使うぶんにはまあ許容範囲
  • しかしフレームワークは重厚長大になろうとしがちなので、そのうち罠にはまる
• Zope2はMixinに害されてしまったため、Zope3はMixinではなくコンポジションを多様した
  • コンポジションは転送(Forwarding)のこと、委譲(Delegation)と似ているが少し違う

PHP界隈でも、Rails wannabeなフレームワークだと頑張って疑似Mixinを実現しているものがあるけれど、利用者からすると必ずしも嬉しいとは限らないということか。PHPだと結局マジックメソッドを駆使して実装することになるから、なおさらコードを追いづらいだろうなあ。

デバッグにかかる時間を予見できなかった理由を問われると「開発現場に突っ込みは入れにくい」と渋りながらも、「要件定義などに問題があったのではなく、要素を実装する段階でのコンフリクトを見極められなかったのだろう」と分析した。

ゲームの開発現場には、いわゆるシステム開発のmethodologyがどの程度取り込まれているもんなんでしょうね。なんとなくEAとかSierraのようなアメリカの巨大メーカーは、そのへん抜かりなさそうなイメージがあります。

そのうち、GDCの資料でも探してみようかな。

どうにかしようと探してみたところ、ShortURLといういいライブラリがあったので、これを使うことにしました。

tinyurl.comを指定すると変換後のURLがうまく取得できないようだったので、デフォルトのrubyurlのお世話になってます。正規表現はあまり厳密ではない。

ソフトウェアの持つ機能・インターフェースの名称は、そのソフトウェアが扱う領域（写真管理、作曲、請求書の作成などなど）におけるDSLである。

これは、37signalsがiPhoto ‘09 and Domain Languageというエントリで主張していることで、言われてみればその通りなんだけど実際にソフトウェアを設計している段階ではなかなか思い当たらないことでもあります。

DSL（ドメイン固有言語 – Wikipedia）といっても実際に何らかの言語でコードを書くという話ではなく、機能に付けられた名称がソフトウェアの挙動や使われ方までもを左右するため、新しい機能やソフトウェアにおける用語は熟慮したうえで決定する必要があるということです。

例えば、37signalsのプロダクトのひとつであるBasecampの場合は「プロジェクトにおける人々のコラボレーション」という問題領域を扱っており、同社ではこれを

• メッセージ
• ファイル
• マイルストーン
• ToDo

というメタファーに切り分けて表現しています。Basecampの例だと具体的な効果がわかりづらいですが、この考え方のよりわかりやすい例としてAppleのiPhotoが挙げられています。

Originally uploaded by Quasimime

Before iLife ‘08, iPhoto’s domain language was the same as any other photo app. You had Photos and you had Albums. Then in iLife ‘08 something changed. Suddenly you also had Events in the mix. This is huge. Apple realized that people don’t just want to find photos. Go back to iPhoto’s domain: it’s that situation where you have a bunch of photos and you want to look at them and share them. When you’re in that situation, you don’t just want to see random photos. You want to see and share photos of certain things. Like photos of your wedding, photos of your trip to Maine, or photos of that dinner in Paris. These are Events. They’re part of the domain, and since 2008 they have been expressed in iPhoto’s domain language.

かつてのiPhotoでは、他のソフトウェアと同様に「写真」と「アルバム」という用語（ドメイン固有言語）が用いられていたが、iLife’08（に含まれるiPhoto）からは「イベント」という用語も使われるようになりました。これはつまり、iPhotoユーザーは単に写真を探したいわけではなく結婚式や旅行といったイベントの写真を家族や友人と見たり共有したりしたいのだ、ということにAppleが気付いたということです。

この考え方が正しかったと言わんばかりに、7日に発表されたiLife’09ではさらに「人々（Faces）」と「撮影地（Places）」という用語も導入されましたが、これもちゃんとiPhotoがどのように使われるかという点を意識した機能になっています。

ソフトウェアやサービスを設計する時には、対象とする業界や競合製品で使われている用語をそのまま真似るのではなく、そのメタファー・用語で問題ないかどうかをユーザーの利用シーンを想定しながらよく考える必要があります。用語を決定するということは、ソフトウェアの挙動や使われ方を決定するということでもありますから。

• Getting Real: Copywriting is Interface Design (by 37signals)
• Getting Real: 日本語訳