あーありがち

過去の日記 2010-02 2010-01 2009-12 2009-11 2009-10 2009-09 2009-08 2009-07 2009-06 2009-05 2009-04 2009-03 2009-02 2009-01 2008-12 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ GWの成果

• MacBook + MacPorts に移行
  • やっと時代（Leopard）に追いつく。しかしTerminalにタブがついたくらいしか自分の使用感は変わらないのであった。
• EPWING広辞苑4ヶ月以上経ってやっと封を切る
• Retrospectiva 試す
• GEOM(FreeBSD) と ufs のお勉強
• FreeNAS 試す
• Selenium IDE 試す
• Ustream のアカウント取って試してみる
  • なんも流してないけど
• xrea+更新

• 行ってみたかったカレー屋を制覇
• 行ってみたかったそば屋を制覇

こんなもんか。ひどい生活してる気がするけど、気にしないでおこう。

_ Preview での回転と Exif

Exif に縦位置、横位置の情報なんてあったのか。知らなかった。

• Preview 4.0 Help: 回転させたイメージが、ほかのアプリケーションでは回転していない場合
• Apple Support Discussions - プレビューで方向を変更した画像の保存について

まぁ以前使っていた GraphicConverter による回転では画素数が何かの倍数（8だったか？）でないと劣化する可能性あるよって警告出てたし、実際に回転させるより速いからこっちの方がいいのかも。

_ PHP の mbstring.language と internal_encoding でビックリした件

いやー久しぶりにビックリしたわ。さすが PHP.

mbstring について何の設定もしていない状態で有効にしてある PHP を用意して以下のコードを動かしてみてください。

.htaccess

AddType application/x-httpd-php .php
php_value mbstring.language Japanese

mbstring.language.php

<?php
print "<pre>";
echo PHP_VERSION."\n";
print_r( mb_get_info() );
mb_internal_encoding( 'euc-jp' );
print_r( mb_get_info() );
print "</pre>";

マニュアル

PHP: mb_language - Manual

によると

• mbstring.language は mbstring.internal_encoding を設定するので mbstring.internal_encoding は mbstring.language のあとで設定しろ
• language が Japanese の場合は internal_encoding は EUC-JP が自動でセットされる*1

と書かれています。

ということは 1回目の mb_get_info() も 2回目も

   [internal_encoding] => EUC-JP

になるはずなんだけど、これ

EUC-JP になったりならなかったりする

というステキな動作をします。え？ なんで？ まったく分からない。何の変更も加えていないこのスクリプトを何度も実行していると、1回目の mb_get_info() の出力が変化します*2。

どういうことやねん

というか、

こんな中途半端な機能ない方がマシです。おっかなくて使えたもんじゃない。

「internal_encoding とか mail_charset とか必要な設定を各自が確実に行いなさい」と言うだけでよくね？ language を設定する意味ってなんなの？

ちなみに確認は

• PHP 5.1.6@CentOS 5.1
• PHP 4.4.8@FreeBSD 6.3

で行いました。

さらにちなみに、Twitter でブータレてたら同じ経験をしている人がやはりいました。

Twitter / ryota ichie: @wtnabe 自分もphq4で経験あります！結局原因...

結構昔からずっとこの動作なんでしょうねぇ*3。すっげー気持ち悪い。まぁ、

internal_encoding をはじめ、必要な項目には確実に明示的に値をセットしてから使いましょう

ってことですな。

_ ようやくアジャイルプラクティス読了

去年の年末 Amazon で手に入らずにキャンセルしてリアルショップを探して手に入れた割にまったく落ち着いて読む時間が取れずにいたものをようやく読み終えた。

いい。

付箋だらけで逆に付箋貼った意味がない。

いくつか拾うと、

• 応急処置による泥沼化
• deploy の自動化
• プロジェクト用語集
• コードで伝える
• Tell, Don't Ask
• ソリューションログ（なんでもチケット化？）
• 警告をエラーとみなす
• アーキテクトもコードを書くべき
• コードをレビューする

辺りが心に残ったり引っかかったりしているところ。

例えば deploy の自動化は今まさに自分がいちばん問題意識として強く持っていることの一つで、PHP の設定って PHP で書いた方がよくない？ なんかは実はこの辺に繋がっている。設定を php.ini の外に出すことでいくつものサイトのコードを同時に扱えるだけでなく、さらにその設定を開発環境、検証環境、本番環境に確実にセットできるようにすることを目指している。さすがに全自動にするのは難しいが、自前の Ruby スクリプトに必要なパラメータをコマンドラインオプションで与えるだけで include_path のセットや symlink の作成などを自動的に行い、できるだけ早くその後の行程に入れるようにということを考え、実践している。

以前 CruiseControl.rb の名前も出したかと思うが、この辺も基本的には同じ。deploy ではなく全体の（ユニットテストではなく）実際の動作チェックを自動化しておくことは非常に大きな安心感、そして自信に繋がる。現在のところこれも自前のスクリプトでゴリゴリチェックを掛けているが、このツールがなければ複数のサイトを一気に PHP 4 から PHP 5 に移行させるには間違いなくもっと多くの時間が必要だったと思う*1。

もう一つはコードで伝えるという辺り。最近、様々なレベルでインターフェイスということをよく意識している。ユーザーがアプリケーションに触れるインターフェイス、コードと開発者のインターフェイス、コードとコードのインターフェイス、アプリとアプリのインターフェイス。で、言ってみれば「コードで伝える」ということはコードと開発者のインターフェイスという辺りの話かなと。

逆にもやもやしているのはコードレビューの辺り。それもコードレビューの方法とかではなく、コミットされる前のコードをどうやってレビューするの？という初歩的な話。だってコミットされていないコードは基本的に開発者のローカルの環境にあるわけでしょ？ ペアプロでもやってない限りコミット前のコードって現実的にレビューできなくないですか？

というわけで今のところ 1 〜 2日で終わらない作業は基本的にブランチ切って、ブランチ内は動いてないコードでもとにかくコミットさせ、そこでレビューすることにしている。なんかこの辺、もうちょっと何か工夫がないのかなぁという気はしている。

自分の話は置いといて本そのものの話をちょっと書いておく。

自分の場合、多くの内容はどこかのサイトや他の本や雑誌などでなんとなく見たことのある内容だったので、時間とやる気がある程度以上確保できた今日はとても軽快に読み進めることができた。まぁ言うなれば復習なので。ただ「書籍としては」アジャイルの本はたぶん初めて読んだと思う。

そのためどの内容もウンウンとうなずくばかりで、その結果が冒頭に書いた付箋だらけで付箋の意味を成していないような状態である。まぁそれだけ内容が「詰まっている」と言える。

ただ「詰まっている」というのは項目の数として内容が多いという意味でもあるが、書籍全体の分量はとてもお手軽な量に収まっているため、一つ一つの内容がそれほど深くないという意味でもある。例えば実際のコードはあまり登場してこないし、個々のツールの説明もかなり少ない。ユニットテストの自動化やデプロイの自動化など魅力的な言葉は並んでいるが、それらを始めるためにどれくらいのコストが掛かるかも、まったくアジャイルの経験も知識もない人には予測がつかないだろう。

そういう意味では実践に移すためにはこの本だけでは不十分で、より多くの情報を集め、自分だけで試せることはとりあえずやってみるなど、それなりに手間ヒマを掛けないとダメな気がする。

とは言えこの「ギュッと詰まった感」はまったく初めての人でも圧倒される心配がなく、入り口として実にいい塩梅に仕上がっていると思う。別なタイトルを考えるとすると、（会社違うけど）

アジャイルHACKS*2

みたいなもんだと言えば通りはいいかもしんない。

オススメっす。

_ dom0 と domU の時計が意図せず食い違うケース

以前書いた内容は間違ってたっぽいんですが、あまり見ないケースだと思うのでとりあえず現象をそのまま書いておきます。

えー結論から言うと

dom0 が正しく ntp サーバと同期できていない domU の時計は dom0 とも食い違う可能性がある

ということです。自分はそんなケースを考えていなかったので、あちこち調べた結果

• domU では ntpd を立てない
• dom0 で ntpd を立てる

状態にして、まさか ntp サーバが調子悪くなってると思わず放置してたのですが、しばらくして domU の時間がずれているなぁという話になりました。いやー dom0 に合ってるはずなんですけど？って返したら dom0 とも違うなぁということで色々調べた結果ホスティング先の用意している ntp がおかしなことになっている。(Stratum 16 とか言う。)

前回はこの現象を早合点して RH 系 Linux の domU は自分で時計合わせなきゃダメなんだ！と思い込んでしまったのですが、実際にはそうではなく、単に dom0 が時計をちゃんと合わせてくれないと domU は domU で dom0 とは独立して勝手にずれていく、ということだったようです。

で、今はデフォルトの状態のまま*1 dom0 でも domU でも ntpd を動かしているのですが、これはこれで変というか。

時計はずれてないけど syslog に ntpd が時計を合わせた旨もエラーメッセージも記録されないのです。10日ほど。ntp の設定を見直したまさにその日にしか記録がない。これはおかしいなぁ。でも時計は正確なのです。

ntpd のエラーってなんか conf に書かないと記録されないんだっけか。LAN 内のものは特に設定しなくてもコマゴマ記録されてるんだよな。この状況はまずいんだろうかまずくないんだろうか。もう一回 domU の ntpd を止めて様子見ようかなぁ。RH 系 Linux はそういうもんなのかな。Debian 鯖と記録のされ方がなんか違うな。

_ 最近見かけた割とまともなWeb制作入門系の本

故あって本屋でWeb制作の入門向けの本を探していて、実際に手に取って確認した中でまともなものをちょっと紹介してみますよ。

全般

ウェブの仕事力が上がる標準ガイドブック2 Webデザイン(益子 貴寛/佐藤 伸哉/浅野 紀予/矢野 りん/植木 真/原 一浩/松村 慎/中村 享介/境 祐司/長谷川 恭久) は数少ない網羅的な本。画像形式とその特徴の違いなど、本来触れていて当然の内容がちゃんと入っている。HTML だけとか HTML + CSS だけとかを扱う本は多い*1が、それだけでは当然 Web の作り手としての知識には十分でない。なのにこういう本が少ないのはとても不思議。ズブの素人の人はいったいそういう大事な知識をどこから得ているの？ 学校で教えてくれるの？ そんなわけないよね？

じゃあ逆になんでこの本はこんなにしっかりしているんだろうと思ったらそれもそのはず、これは「Web検」の教科書的な位置付けの本なのだ。「Web検」てそう言えば聞いたことあるなーと思ってはいたけど、今サイトを見ると一応試験は始まっているみたい。システム寄りの方はまださっぱり内容もないけど。

社団法人 全日本能率連盟登録資格「Web検定（ウェブケン）」 - Webに関わるすべての人の標準知識

正直Web検には別に何も期待していなかったんだけど、まともに使える本が出るだけでもかなり大きな意味があるような気になった。自分が徐々に、断続的に手に入れてきた知識をまとめて相手に伝えることは難しい。そのまとめの作業をそれなりに肩代わりしてくれる本の存在はとてもありがたい。

制作／デザイン寄り

HTML を組むには以下のような感じですか。

• Web標準XHTML+CSSデザイン クリエイターが身につけておくべき新・100の法則。(加藤 善規/平澤 隆/両見 英世)
• Webユーザビリティ・デザイン Web制作者が身につけておくべき新・100の法則。(石田 優子/有限会社 アルファサラボ)

世の中の HTML の解説には、かなりひどい間違いを含むものが大量に出回っていることは皆さんご承知の通り。その一つ一つについてちゃんと検証したわけではないので、ぶっちゃけこの本がそんなに「正しい」かどうかは分からない。基本的には「姿勢」で選んだ。

• 下手に漫画調にしてごまかしていないこと
• それでいて図が豊富で分かりやすい
• スクリーンショットだらけでブラウザの挙動ばかりを気にするのではなく、構造などの基本を大事にしている

てな辺り。

最近 Web の入門系の本なんか見る機会がないから知らなかったけど、探すと結構「Web標準」という言葉を目にする。「あー認知度上がったんだなー。」と感慨ひとしお。そういう中で探すと割とまともな本にたどりつきやすかった。ただやっぱ見やすさ、扱いやすさという、内容以外の要素も重要で、実際上に挙げた本は割と見た目を重視している。要は一人でこの本でめげずに独学していける*2と直感できる本を選んだつもり。

cf.

• うん、これは自習にいいかも - あーありがち (2008-09-08)

_ 複数の diff を一気に見る GUI のツールってやっぱりないの？

terminal 原理主義の自分は当然

svn diff

svn diff | awk '/^Index/'

svn diff | awk '/^Index/ {print $NF}'

for i in `svn diff | awk '/^Index/ {print $NF}'`; do svn diff $i | nkf -w ; done | less

みたいなことをしてるんだけど*1、GUI のツールにこういうことのできるものを見かけたことがない。なんでだろう。

何が言いたいかというと、例えば TortoiseSVN などで commit する際、変更のあるファイルがリストアップされるでしょ？ で、その diff を見ようと思ったら別な diff ツールに渡さなきゃいけないんだけど、そのとき一つ一つ開かないといけないのって面倒くさくない？って話。（これが間違いなら今回の話はもう全然意味ないです。）

ファイル一つだけで済んでるうちはいいんだけど、例えばメソッドを追加したのでプロダクトコードとテストコード両方いじりましたとか、テストデータもいじりましたとか、変更が複数のクラスに入りましたとか、あるわけじゃないですか*2。このとき、GUI 使いの人たちはどうやってその変更を一覧するのだろう、という疑問です。

いやね、絶対一覧できなきゃいけないってわけじゃないんだけど、一覧を見てるうちに「あれ、そういえばさっきいじってたファイルを add し忘れてるな」とか「しまった、何の気なしにちょっといじっておいたものをそのまま commit するところだった」なんてことに気づくことがちょこちょこあるし、複数の diff の間でうまく対応が取れていない*3ことに気づいたりするし、実際身近な GUI 使いの人の commit 忘れが自分より多い気がしてるのです。当然、使い手の個性もあるでしょうが。

第一、GUI の diff ツールって、確かにきれいに見えるんだけど実際の変更以外も全部表示されてるから、例えば変更の入った部分がファイルの末尾の方ばっかりとかだとスクロールがうざくないですか？ コロコロコローって*4。そういうのって設定次第でどうにかなるもんなの？ それでもやっぱ開いたり閉じたりしてるうちにさっき見てた diff の内容が頭から飛んじゃわない？ 飛ぶよね。なんかやっぱ GUI の diff ツールって、書いてる途中のファイルの diff が見れればそれでいいと思ってんじゃないかって気がすんだよなぁ。

まとめ大事だよ、まとめ。まとめて見ようよ。

_ Trac に PeerReviewPlugin を入れてみた

先日、ようやくアジャイルプラクティス読了 で

コミットされる前のコードをどうやってレビューするの？という初歩的な話。だってコミットされていないコードは基本的に開発者のローカルの環境にあるわけでしょ？

と書いていたけど、そう言えば reviewboard なんてものがあったなぁと思い出して動かすことを試みた。しかし

monospace blog オンラインソースコードレビューツールのReviewBoardをインストールしてみた

にしたがって Debian etch で作業してみたがあえなく失敗。（Python Image Library が入らなかった。Django も経験ないし。）

気分を替えて Trac に PeerReviewPlugin - Trac Hacks - Plugins Macros etc. - Trac をインストール。こっちは Trac の plugin 特有のクセを把握できてなくてちょっと手間取ったけどなんとか動いた。

※ Trac 0.10.4 with Apache 2.2 + mod_fastcgi on FreeBSD 6.3R と Trac 0.10.3 with Debian etch + Apache 2.2 + mod_python 3.2.10 で確認。

やったことは以下の通り。

1. PeerReviewPlugin を Python モジュールとしてインストール
2. Webサーバの方へ EGG 周りの設定を追加
3. trac.ini で Trac インスタンスについて有効に
4. trac-admin で権限を付与
5. trac-admin PATH upgrade

plugin を Python モジュールとしてインストール

TracPlugins The Trac Project Trac のまま。

• setuptools( easy_install ) をインストール
• easy_install で PeerReviewPlugin をインストール（EGG として Python の site-packages に入る）

Trac のバージョンによって対応するものが違うのでそれに合わせてインストールすること。easy_install に慣れていなかったのでどこで何を指定して easy_install を起動すればいいのか分からなかったけど、エラーメッセージや back trace を読みながらよちよち作業を進めたらなんとかなった。こういうとき Python や Ruby で書かれたツールは助かる。

しかしあとになって実は下の Google Group のリンクをたどれば何をすればいいかが分かった。今回インストールしたのは 0.10 用のものなので

sudo easy_install http://trac-hacks.org/svn/peerreviewplugin/0.10

でよかった*1。

WebサーバにEGG用の設定を追加

以前 WebAdminPlugin を入れたときにももしかしたらやってたのかもしれないけど、あれは別な環境でやっていたのですっかり忘れていた。EGG は cache を指定しなければいけないらしく、FastCGI で動いているうちの環境では

 FastCgiConfig -initial-env TRAC_ENV=/var/lib/trac
+              -initial-env PYTHON_EGG_CACHE=/var/lib/trac/plugin-cache

を書き足した*2。（パスはサンプルに載っているまんまなので適宜書き換えること。）

使いたい Trac インスタンスについて有効に

この部分の記述が全然不十分で手間取った。

trac.ini の中で

cannot install peerreview (not picked up) - trac-peerreview-dev | Google グループ

に従って

[components]
codereview.* = enabled

で plugin を有効にする。また

/peerreviewplugin/trunk/README.txt - Trac Hacks - Plugins Macros etc. - Trac

に従って

[trac]
mainnav = ..,peerReviewMain,..

を編集してメニューに組み込む*3。

権限の付与

trac-admin PATH permission list

とすると

• CODE_REVIEW_DEV
• CODE_REVIEW_MGR

が追加されているのでこの割り当てを行う*4

使用感

ほんとに試しただけだけど、

1. Trac の plugin なので当然 review 対象は reviewboard とは違って*5 repository に commit 済みのコードの一部
2. review の作成は 3 step か 4 step で、Ajax を使っていて難しいところはほぼない

という感じ。1 は運用ルールによっては問題になるけど、現状自分が関わっている部分では大丈夫かなと。

とりあえず Django のセットアップとか慣れないことをやらずに記録の残るレビューができそうなのはよさげだなと思っているところ。メール飛ばしたりなんだり、本格的には使っていないのでその辺は分かりません。

え？ Retrospectiva はどうしたのかって？ どうしましょうね。こうして plugin を使い始めると移行するのは難しいよねぇ。でもやっぱこういうプラグインのセットアップも Trac インスタンスごとにやらなきゃいけないのはイヤなんだよな。

[2008-06-02 追記] Review の様子が timeline に出ないぞ？ timeline に出なかったら Review の追加はどうやって知るのだ？ メールとか飛ばす設定があるのか？ うーん、そりゃあどうだ。不便じゃないか？

Ticket みたいに Search の結果の feed を吐けるのかな、と思ったけどそんなこともない。というか自分宛に依頼のあった Review という条件では検索はできない。（まぁ My Code Reviews で出てはくるんだけど。）なんだかな。なんだかなぁ？ 0.10 だからかい？

[2008-06-04 追記] あれ？ Wiki の [source: link] 形式の記述が Source Browser じゃなくて peerReviewBrowser への link になって怒られるぞ？ えーー。なんだよー。ダメじゃんよー。何乗っ取ってんだよー。

_ 『インターフェイス指向設計』読了

最初にオススメポイントだけ書いておく。この本には

• テスト容易性の確保
• 複雑性保存の法則への対処

へのヒントが詰まっている。

kakutani.com にアサマシセンターがあるのかと思ったけどなかったので自分ので貼っちゃうよ。献本なのに自分のアサマシ貼ってるなんてふてぇやつだよ、オレ。

読み手に推奨される準備

まずはじめに「本書の読者対象」を挙げておくと、

本書は、ある程度のプログラミング経験と、オブジェクト指向設計の基本的な知識を持つ開発者を対象にしています。オブジェクト指向に深い造詣がある読者でも、インターフェイス指向のアプローチを学ぶことで、これまでにはなかった設計の概念を得ることができるようになるでしょう。また、インターフェイスを理解することは、SOA（サービス指向アーキテクチャ）の設計においても有用です。

と書かれている。

正直に告白すると自分はこれをなめていた。普通に UML もデザインパターンも出てくる。もっとも、この本に出てくる図は十分に簡単だし最低限の説明はなされている。またデザインパターンもインターフェイスに注目してごくわずかしか出てこない。なんだけど、覚悟しておくのとしていないのとでは雲泥の差。早めに覚悟しておこう。UML もデザインパターンも普通に出てくるよ。

あと前提知識としては当然 Java 的な意味での interface（PHP 5 以降にもあるね）、あるいは Ruby で言う Module がどういうものか分かっていないとつらい。それに継承の問題について自覚的であった方がよい。継承がいかに扱いにくいかを普段感じていないと、サンプルのコードだけではいたずらに複雑になっただけに感じられてしまう。丁寧に書かれているんだけど、問題意識がなければたぶん通じないんじゃないかな*1。

内容

I部、特に3章と4章では本書で扱うインターフェイスに関する用語が怒濤の勢いで出てくる。リファレンス的な部分。その前の2章で契約というキーワードでインターフェイスを考えるための材料が整理されている。

またこの中でさりげなくだけど何度もインターフェイスの変換について触れられている。これはのちのち効いてくる。

5章ではポリモーフィズムを継承ではなくインターフェイスを使って実際に組み立てていく。Role を使ってフットボールチームの話をしているうちはよかったんだけど、Java の InputStream に縁のない自分はちょっとこの辺で意識が飛んでしまった。

II部では開発を進める段取りと実際の作成。7章でインターフェイスに注目しながらユースケースを作り、それをテストしようと試みる、IRI カードなどの話。メソッドが明確になったら実際にテストコードが出てくる。8,9,10章は動くものの話。内容的には Web 系が中心でなじみやすい印象。

最後 11 章でインターフェイス指向からパターンをおさらいして終了。

感想

一言で言うと素晴らしくオライリーらしい。歯ごたえたっぷり。悪く言えばもっと内容を噛み砕いてほしかった。噛み砕く手間と分量で値段は上がってしまうだろうけど、この本は例え1000円高くなっても3600円。十分通用するんじゃないかなぁ。オライリーだし。

実際のところ特別難しいわけじゃないと思うんだけど、個人的な好みはもっと図やサンプルを多くしてほしいんだな。自分は言葉だけでは覚えられないタイプで、何かしら頭の中にビジュアルやアニメーションが思い浮かべないとダメなんで、それを用意しておいてくれるととても嬉しい。いやユースケースやシーケンス図や IRI カードは出てくるんだけど、なんかそういうものじゃないんだなぁ。うまい言葉が見つからない。

なんていうか結構いろんな説明がサラッと出てきていて、もったいないなぁと感じる部分がちらほらあった。ここは重点的に説明しようと感じられたのは「継承とインターフェイス」の部分くらいで、あとは「ま、フツーに知ってるよね？」的な印象。Dependency Injection なんか「あるいは Dependency Injection パターンを用いて実装を設定できます。」とか「おいおい、それだけ？」みたいな。実際のコード間のインターフェイスをどう作り上げていくか、すごく大事な部分のような気がするんだけど、その辺はインターフェイスに注目して分析、設計していく過程としてはあまり重視されていないのかしら。それともやはり使えて当然か*2。そういう意味では経験で補いながら、手を動かしながら読む感じ。例えば DOM と SAX の違いってサンプルコードだけで分かるのかな。自分は幸い両方経験があったからすんなり分かったけど、そうでない場合は一つ一つ噛み砕くのにそれなりに時間掛かるんじゃないかな*3。

あと当然なんだけどインターフェイスという言葉がたくさん出てきてその意味が文脈によって変わるので、特に前半の説明の部分でなかなか頭の痛い思いをさせられた。より一般的な常識的な意味でのインターフェイスであったり、ある程度の機能のまとまりを意味していたり、Java用語的な Interface を意味していたりする。その使い方をいくつかに分類して、ここではこういう意味、ここではこういう意味と、例えば type face を変えるなどして明確にできていたらこれはかなり画期的な本になっていたのではないかと思う。

なんだろう、この出だしの滑らかさとは裏腹にいきなり歯ごたえたっぷりな内容に移行する感じ、覚えがある…と思っていたら、読み終える直前に気づいた。

この本、『プレファクタリング』の人が書いてた。

実はわたくしこの『プレファクタリング』、途中で挫折しております*4。いちばんの理由は Java のコードを読むのがたるいというものなんだけど、今回も終盤はその呪いを解くことはできなかった。だいぶ端折ってしまった。疑似コードもあんまり読みやすい気がしなかったけど、これはオレのセンスがないのかなぁ。内容はいいと思うんだ、内容は。

オライリーの本て、なんかそういうとこあるよね。*5

ただ思いっきり自分の言葉で要約すると

• テスト容易性の確保
• 複雑性保存の法則への対処

へのヒントは確実に詰まっていると思う。高凝集、疎結合という言葉が帯にはあるんだけど、自分としては上の二つの言葉の方が断然しっくりくる。この視点で振り返ると、インターフェイスの変換の話がいくつも出てくるのは実はこのためかと気づく。

オススメと言えばオススメ。でもコレ読むとすごくよく分かるよ！新しい発見があるよ！という意味ではなく、これは通過しておくべき、という意味なのかなぁ。さらっと読めば読めちゃうと思うんだけど、さらっと読んじゃダメというか。たぶん自分はこの先何回もこの本を開き直すと思う。API を使ってゴニョゴニョとかするときにもそのインターフェイスの意味、機能、他のインターフェイスへの変換などのヒントになると思うから。

とりあえず今度もう一回『プレファクタリング』に挑戦してみる。今見直したらプレファクタリングにもインターフェイスの話出てくる。あー、今読めばイケるかもな、これ。コード全体を変更に強くする、どちらかというと実装のためには『プレファクタリング』を、分析、設計のためには『インターフェイス指向設計』を読むのがいいみたい。まさに合わせて読みたい。

あとちゃんと『リファクタリング』と『達人プログラマー』も読んだ方がやっぱいいんだよね？ （実はちゃんと読んだことがない。）

直接関係しないんだけど、PHP 5 で interface が入ったじゃないですか。でも名前空間は相変わらずないんですよ。なんか interface の機能はいいんだろうけど、名前争奪戦が激しくなるだけなんじゃないの？という印象を持ちました。やっぱまだロジックは Ruby で書いてテンプレートを PHP で書くのが最強という印象は変わらないなぁ。

_ フレッツ光に移行

※ 思い出して昔の日記を書くメソッド。

工事そのものは予想していたものよりはずいぶん簡単だった。とは言え事前調査がなぜかパスになってしまったので、ケーブルがどこから出てくるのか分からず担当の人は難儀していたけれど。

やったことは壁の電話線のカバーを外してジャッジャッと黄色と黒のケーブルを差し込んでいって、建物の中のケーブルがまとまっているところで繋ぐ作業と、屋内では外したカバーをアナログ線専用のものから光/アナログ兼用（両方刺さる）ものに変更し、あとは機材を設置、接続試験をしておしまい。

光用の機材は 3つ。思ったより存在感があり、それぞれ電源を要求するので非常に邪魔な感じである。電話機のアダプタを加えるとそれだけで 4つ。うちの場合はそれに加えて AirMac Express と自宅サーバ用の電源も要る。あーおまけに携帯の充電スタンド用のものもあるんだっけ。うちの電話台はものすごく賑やかなのだ。

ところで話は変わるけど工事に来た人が軽くドレッドで、携帯の着信音は Dragon Ash だった。なんだか分かりやすい人だなぁ、きっと根はいい人なんだろうなぁとか、実は工事の間中そんなことを考えていた。その曲なんでしたっけ？と何度聞こうと思ったか知れないが、やはりタイミングを逃した話題を振り直すのは難しい。あーなんだったっけなぁ。

（……しばらくお待ちください……）

Let Yourself Go, Let Myself Go でした。ぜってーすっげー有名な曲だよ、と思っていたんだけど、意外に見つからなかった。確か当時なぜか Dragon Ash も 1枚くらい聴いておかなくちゃと思って聴いていたアルバム Viva La Revolution の中に入っていた。これ聴いて、ロックなのかヒップホップなのかよく分からんと思いながら Rock the beat がちょっと気持ちいいなぁと思っていたっけ。

懐かしいな。

あーそうそう速度的にはたぶんおよそ40〜50倍出るようになりました。うちは ADSL 僻地で数百kbpsしか出なかったんだけど、5MB/s くらい出るようになった。すげーじゃん、光。ネット難民時間はおよそ3時間くらい。CTU の穴開けにちょっと手間取ったけどあまり難民にならずに済んだのでよかった。