Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.Braritemeal(2008-08-25 00:41)
2.dyendignify(2008-08-18 10:20)
3.Dominic(2008-06-23 05:05)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
"mciML"は前回と変わらず第11章"Register Allocation"。前回から1ページだけ進み241ページまで読了。先に章末の演習問題を解くことにしたが、ハマる。とは言ってもレジスタ割り付けの具体的な手順のうち、解釈を間違えていた部分がいくつか見つかったので、演習問題に時間を掛けた意義は十分にあったようだ。その一方でまだしっくりこないところも沢山残っている。なんというのかな、「カチっとはまる」感覚が得られないまま、解いた後も「この解答で本当にいいのかな？」と迷い続けるカンジ。アルゴリズムにヒューリステックスが多用されてるのが原因なのかも知れないが、実際のところはよく分からない。
12/23に聴き始めたAudiobook"Shadow of the Hegemon"(Orson Scott Card)を読(?)了。終わりかたがやや中途半端だったので少々調べてみたところ、"Shadow Puppets"という続編があることが分かった。すぐさま購入してダウンロードする。前回の購入時の購入価格は$9.95だった（本来の価格は$35…なぜ安くなったのかは謎である）が、今回は$28と、少々高い。PremiumListenerという定期購読プログラムにするとかなり安上がりになるようなのだが、毎月の会費が自動引き落としされるシステム、しかも解約にはアメリカまで国際電話（！）で連絡しないといけないというのが気に食わない。さて、どうするか。
第11章"Register Allocation"の252ページまで進む。レジスタ割り付けのためのアルゴリズムが10ページ近くにわたる擬似コードで説明されている箇所であるが、一回読んですぐに理解することなど到底望めない。一度流し読みを行い、腹（頭？）におさめたところでゆっくりと消化する方針をとる。ヘビが大きな獲物を「丸呑み」するイメージである。コードを書き始めるにはもう少し時間が必要。
1月2日に聴き始めた"Shadow Puppets"(Orson Scott Card)を読(?)了。Orson Scott Cardのページに行くと、さらに続編として"Shadow of the Giant"という作品が3月に刊行予定、とある。Audiobookで登場するのはもうしばらく先ということになりそうなので"Shadow"シリーズはとりあえずここで一段落。最初は重くて高いハードカバーで発売されるだろうし、自宅の本棚が一杯になりかけていることも考えると、Audiobook化されるまで待つのが良さそう。
audible.comのAudiobookは非常にイイ。電車の中で立ったまま、ベッドの上でねころんだまま、果ては歩きながら（といっても危ないので人通りの少ないところでね）本が読めるというのはとにかく便利でラクなのだ。しかも本棚の（残り少ない）スペースを埋めなくて済む。素晴らしい。使っているといくつか気になるところも見つかるが、ちょっとした工夫で解決できるものも多い。ここではそのような工夫、というか小技を3つほど書き残しておくことにする。
■ その1：CD-R/RWへの書き込み速度の改善
当初、CD-R/RWへの書き込みにかなり時間がかかる点が気になっていたのだが、AudibleManagerの[Tools]-[CD Burner Properties...]からCD-R/RWへの書き込み速度が設定できることが分かった。デフォルトは1倍速（ぉぃ）なので、ここを変更することであっけなく解決。手持ちのCD-RWのメディアは最大で4倍速までしか対応していないのでアレだが、それでも非常に快適になった。書き込み後すぐにMP3化したい場合には"Eject CD after recording"のチェックボックスも外しておくとよかろう。（←最新版では設定が無くなっていたので訂正）
■ その２：audible.com内の特定のページへのリンク
日記などの文章の中で、audible.comの特定のページへのリンクを設定したいとき、目指すページのURLをそのまま貼り付けてしまうと、後からクリックしたときに「セッションがタイムアウトしました」という悲しいページが表示されてしまう。そもそもURL自体にセッションIDが埋め込まれていたりするのであまり美しくないのである。audible.comのページの左端のメニューにある"Become an Affiliate"というリンク経由で見つかる"Link Generator"というページを使うと、直接リンクをするのに適したURLが表示される。これには少々無駄な情報が付加されているのでこれを削ったものをリンクとして貼り付ければよい。"Link Generator"はAffiliateにならなくとも利用可能。イレギュラーな使い方ではあるが禁止はされていない。
■ その３（実験中）：ギフト用定期購読プログラムを使う
1月2日の日記では"Premium Listener"という定期購読プログラムに入ると、月ごとに自動更新され、かつ解約が面倒である、という話を書いたが、"Gift Center"セクションのところを見ると"Premium Listener"の1ヶ月ないし3ヶ月の利用権がプレゼント用に購入できる、ということが分かる。これを購入して自分で使うとどうなるだろうか、ということで実験してみた。題して「俺様プレゼント作戦」（呼び名からして駄目っぽさ全開）である。"Premium Listener"の1ヶ月利用権（1ヶ月の期間中に2冊のAudiobookがダウンロードできる。料金は$21.95）を購入し、すぐさまこれを自分で使う。うまく行けば1ヶ月限定、自動更新無しの"Premium Listner"プログラムになるはず、と期待するのだが…2冊分のダウンロード権のうち1冊は"The Da Vinci Code"に使うことに決定。うまく動いているようだ。ところが"Premium Listener"利用権を有効にした後の画面をよく見ると、"Renewal Date: 02/11/2005"という表示が出ている。まさか自動更新されてしまうのではないかと不安になるが、そうなったらなったでしょうがない。まずは2月11日になるまで様子を見ることにする。さて、どうなることやら。
先週はレジスタ割り付けのアルゴリズムを一通り眺める、いわば「丸呑み」をするところまで進めた。今週はその「消化」にとりかかる。「消化」をしているときに頭の中でどのようなことが起きているかを説明するのは至難の業だが、図の助けを借りて説明してみることにしたい。
"mciML"の244ページから249ページにかけて、擬似コードで記述されているアルゴリズムの参照関係を、Graphvizで表示させるとこのようになる。
かなり入り組んだ図であるが、この中にある"Coalese"と、それに関係するノードを取り除くと見通しは少々良くなる。
まずはこのあたりを足がかりに攻めることする。さらに理解を進めるには、アルゴリズム同士の参照関係だけではなく、アルゴリズムとデータ構造の参照関係も整理しておかなければならない。下の図は、データ構造を灰色の四角で表し、アルゴリズムとの参照関係を矢印付きの線で示したもの。
ということで、図をいろいろと並べてきたが、単に図示できるようになった、というだけでは全く足りない。いわゆる「腑に落ちる」状態になるには、上の図で示されるような概略と、擬似コードの細部を何度も行ったり来たりすることが必要になる。図が理解を助けてくれることは間違いないが、それだけで全てをまかなうことが出来ないのも、また事実である。
"mciML"は引き続きアルゴリズムの消化。1月16日の日記内の2枚目の図にある"LivenessAnalysis"と"Build"、"AddEdge"のアルゴリズムの詳細を読み進める。下の図で色が付けられたノードがそれである。
"LivenessAnalysis"と、"Build"に相当する部分は前の章（第10章）で既に作成済みだし、そこで作成したコードがほぼそのまま使えるだろうと思ったのだが…どうも勝手が違う。扱っているデータの表現形態が、現在の章とその前の章で微妙に異なっているのだ。「記述の断層」とでも言うべきか。まだまだ苦労しそうな気配である。
昨年の10月6日から読んでいた"TCP/IP Illustrated, Volume 1"(W. Richard Stevens)をやっと（！）読み終える。タイトルにある"Illustrated"とは「図解」ではなく、「詳解」のこと。日本語版のタイトルも「詳解TCP/IP」となっている（エラい）。TCP/IPの基本について、微に入り細にわたる説明が500ページ強にわたってつづられた本。内容の濃さとボリュームはとにかくすさまじいばかり。生半可な解説本とは全く次元の違う「格」を感じる。
Stevensの本としてはもう一冊、"Advanced Programming in the UNIX Environment"（2000年10月に購入）を持っているが、300ページあたりで止まったままである（総ページ数は700ページほどなので半分にも届いていない…）
1月12日から聴いていたAudiobook"The Da Vinci Code"(Dan Brown)を読(?)了。いやぁ、これは確かに傑作だわ。話の内容も良いし、普通の本として読んでも十分に面白いはずなのだが、Audiobookになるとその価値はさらに数倍にも感じられる。朗読者（ナレーター）が、男女の違いは言うに及ばず、子供から老人まで、大学教授から受刑囚まで、果てはアメリカ英語からイギリス英語からフランス訛りの英語、そして本物のフランス語まで使いこなして何人もの人物を演じ分ける様子には圧倒された。ここまで来ると、もはや単なるナレーターではなく俳優と呼んだ方が良いだろう。"Da Vinci Code"の朗読者であるPaul Michael氏の名前で検索すると、こんな記事が出てきた。以下抜粋：
訛りの表現は大きなテーマである。Brick氏が（SF小説の）"Dune"を担当した際には、未来の世界に住む部族の話す架空の言語について、また、マフィア小説の"The Godfather Returns"では、イタリアのシチリア島のさまざまな方言についてコーチングを受けた。大ヒット作"Da Vinci Code"の朗読者の選定においては、それらしく聞こえるフランス訛りが出来るかどうかが勝負の分かれ目となったが、そこでBrick氏は競合するナレーターである、Paul Michaelという人物に敗れた。それ以来Brick氏はフランス語のレッスンを受けている。
(CareerJournal.com "Books-on-Tape Narrator Finds a Profitable Niche", 超やさぐれ訳)
そこまでやるんだ…脱帽。
結局のところデザインパターンとは、薬のようなものなのだと思う。薬は病気を治す上で計り知れないほどの効果をもたらすが、病気でない人間に使っても意味がないばかりか有害なだけである。デザインパターンもまた然り。
■ デザインパターンの「処方」
デザインパターンにもちゃんとした「処方」がある。鷲崎さんによる講演「ソフトウェアパターン研究の現在と未来（完全版）」内の、「パターンの記述」の説明を借りるならば、パターンの記述においては、まず最初にパターンの名前を提示した後、
をまず示し、その後にはじめて
を記述することになっている。いわゆる「パターン本」の元祖として知られる"Design Patterns"（日本語版は「オブジェクト指向における再利用のためのデザインパターン」）ではさらに、解決策の説明に続く"Consequences"という項で、そのパターンを使った場合の効能と副作用についても、きちんと説明しているのだ。
■ 「解決」だけに走る使い方
ところがいつの間にか、上に示したパターンの記述のうち、「問題」「状況」「フォース」、そして「効能と副作用」を見ずに「解決」だけに注目するケースが目立ってきたように見える。
15:00〜16:40のセッションは「君ならどう書く」。各言語の代表が事前に与えられたお題をどう解いたか、披露するというもの（発表資料など詳細はこちらを参照）。前半は「ls -lR シェル」。「デザインパターンを利用してコーディングすることを条件とし」というルールであったが…
（やさぐれ日記2004年8月7日「"Lightweight Language Weekend"1日目」）
考えられる問題点の一つとしては、パターンは無条件に良いものであり、パターンを多く使うほど品質の高いプログラムが作られると考える人が登場してしまうことが挙げられる。"hello world"を表示するだけのアプリケーションに、decoratorパターンを三つ、strategyパターンを二つ、そして山ほどのsingletonパターンを使ったとかいう怪談も、そういったところから生まれるわけだ。
（Martin Fowler "Patterns"/訳はやさぐれ日記2004年3月26日「『将棋の定跡』と『デザインパターン』」によるもの）
直面している問題も状況も見ずにパターンを使うのはナンセンスだ。また、「とても役に立つ」ことがすなわち、「好きである」ことに直結するわけでもない。「あなたの好きなパターンは？」といきなり聞くのは、いきなり「あなたの好きな薬は？」と聞くのに等しい。
先生も先生で、「きみのお気に入りのパターンは何かね?」とか聞くもんだからタチが悪い。
（メモ 2004年11月(1)。）
…だから、質問状にあったじゃないですか。「好きなパターンはありますか？」っていう。ありません（笑）。
（ＯＯエンジニアの輪！〜第３回 青木淳さんの巻〜）
■ 診断
薬を使う前には診断が必要となる。デザインパターンを使うときの「診断」とはどのようなものになるだろうか？
高木さんがかつて、Java-House Brewersメーリングリストの中で述べていた言葉が最も的確にそれを言い表していると思われるので、以下に引用する：
もしパターンを適用していなかったら、元（の再利用性に乏しいコード）はどう書かれていただろうか？ということを考えてみるとよいでしょう。
（JavaHouse-Brewers:18211）
上の発言では「コード」というキーワードが登場している点にも注意したい。プログラム上の問題点（症状）は、最終的にはコードレベルで現れるのであって、これを見定めずにパターンを使うのは危険であると最近の僕は考えている。
無論、予防薬というものも当然存在し得るだろう。だが、これを正しく使うには、これからコードとして出現するであろうものを予測できるような、経験と洞察がどうしても必要となる。うかつに使って効果が無いだけならまだ良い。副作用でプログラムが死んでしまっては元も子もないのだ。
■ 最後に
以上、「デザインパターン」を薬になぞらえて話をしてきた。薬が人間にとって非常に役に立つことについては疑問の余地はないし、僕も問題が発生しそうなコードに対しては、その問題を解決するためにデザインパターンを遠慮なく使う。
だが、病気でないのに使う薬のことを、世間では「ヤク」と言う。僕としては「ヤク漬け」のコードだけは書かないように心がけて行きたい、と思う次第である。
1月26日から読んでいた"Tales from Earthsea"(Ursula K. Leguin)を読了。日本語では「ゲド戦記外伝」として知られる本。
以前書いた日記(2004年10月6日)では、本作の前の作品である"Tehanu"について
いわゆる『おとぎ話』("The Tombs of Atuan")のエンディングから数十年が過ぎて、その登場人物たちがどのように生き続けているかを描いた本。と言ってもこのシリーズ自体、単なるおとぎ話と言うには重過ぎるのではあるが。
と書いたが、この本(Tales from Earthsea)の前書きで、作者のUrsula K. Leguinも
ゲドとテナーの物語が『そして、彼らは幸せに暮らしましたとさ(happiliy-ever-after)』というかたちで終わりを迎えたと、おろかにも思い込んだ私は、（前作の"Tehanu"に）「ゲド戦記最後の書(The Last Book of Eathsea)」という副題を付けた。
と言っているのを見たときに、自分の声が、作者の口からこだまとなって返ってきたような気がした。もちろん向こうの文章はこちらが日記で書いた文章の前に書かれたものだし、指している作品も異なるのだが、それでも、なんとなく嬉しくなったのであった。
"mciML"は引き続き第11章"Register Allocation"。まずは
という方針を決め、再びアルゴリズムの前半部を眺めながら突破口を探そうとしたが体力切れにて挫折。春は何時くることやら。
# かたきた [一呑みにしたる大蛇あり ]