« Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 1 | トップページ | Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 3 »

2014年11月23日 (日)

Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 2

 Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野子,久野靖訳 1 から続く。

1章 正規表現マッチャ(ブライアン・カーニハン)

 がむしゃらにプログラムを作り始めた頃、「動けばいいってモンじゃないんだぜ」と教えてくれたのが、この人の著作「プリログラム書法」。そんなわけで、私にとっては導師でもあるお方。じっくり読ませていただきました、はい。

 今回取り上げたのは、「ソフトウェア作法」で取り上げたのと同じ、正規表現。ちなみにかの本では正則表現と訳していた気がする。メタ文字は4つ。任意の1文字を示すピリオド,先頭を示すキャレット、末尾を示すドル、0個以上の繰り返しのアスタリスク。プログラム言語はもちろんc。

 unicodeに対応してない等の不満はあれど、サンプルのシンプルさは見事。と同時に、文字列をバイト列で表現すれば充分だった当事の環境が羨ましいし、また ++ や -- などの演算子をc言語に持たせた設計センスの巧みさを、改めて思い知ったり。ホント便利だよね、インクリメントとデクリメント演算子。また式の中で関数を呼び出せるのも嬉しい。

2章 Subversionの差分エディタ:存在論としてのインターフェース(カール・フォーゲル)

 実は Subversion は使った事がなくて、よくわかんなかったりするけど←をい

よい設計の出どころについて多くの人が薄々気づいている点を裏付けるように、差分エディタは1人の人物によって、ほんの数時間の間に作り出されたものなのです(ただしその人は、対象とする問題やコードについて熟知していました)。

  うんうん、まったく。解くべき問題を良く知っている人が、優れた設計者になる。これは当たり前だけど、大事なのは次。多くの人が民主的に設計するより、一人の人が独裁的に設計する方がいい。これは特にインタフェースに関して言えて。

 インタフェースは全体を通しての一貫性が重要で、それには強烈な個性を持つ一人が独裁するのがいい。クセが強ければ、使う側も「このシステムはそういうクセがある」とクセを飲み込みやすい。インタフェースに限れば、下手に妥協しない方が良かったりする。

3章 私が決して書かなかった、一番美しいコード(ジョン・ベントリー)

 古くて新しい課題、整列の問題。クイックソートについて、c言語で説明してゆく。「珠玉のプログラミング」の著者らしく、所々に著名人の警句を散りばめた文章が楽しい。また、クイックソート誕生のエピソードも、なかなか意外。

 私が初めて書いた整列プログラムはN!の処理時間がかかるシロモノで、中身は、まあ、ご想像の通り。上手に作れば平均NlogNで動くクイックソートを、どうチューニングしていくかだけでなく、どう速度を予測するかに重点を置いている。

4章 ものの見つけ方(ティム・ブレイ)

 HTTPサーバ(たぶんApache)の大量のログから、統計データを取り出す話。最も人気のある記事は何か、最も混む時間帯はいつか。当初 ruby で作り、次に perl で最適化する…というとプログラム言語の実行速度の問題っぽいけど、実はデータ構造と設計がキモだよ、みたいなオチなのが楽しい。しかしこの本の著者、皆さん二分探索が好きだなあw

 この本は最適化の話がアチコチに出てくるんだけど、サラリと重要な事をやってるのが、この章。大抵の人が最適化する前に、ちゃんとその効果を予測してる事。この章では、「どこで処理時間を食っているか」を測り、結局は最適化を諦めてたり。

5章 正しく、美しく、速く(この順番で):XML検証ソフトの設計から(エリオット・ラスティ・ハロルド)

 Java でXMLパーサを作り、最適化してゆく話。パーサはテキストを1文字づつ見ていくので、文字ごとの処理にかかる時間が性能に大きな影響を与える。ここでは、「Unicode文字が数字か否か」を調べる関数を例に考察してゆく。処理系の最適化機能を見越すあたりはさすが。でも結局は予め用意した表と、その場で作るキャッシュなのねw

 どうせここまでやるなら、いっそYAML(→Wikipedia)かJSON(→Wikipedia)で属性表を…いや、やっぱXMLでやるのが王道…と思ったけど、それを読み込むためにはXMLパーサが必要なのであった。意味ねえじゃんw

6章 テストのための統合的フレームワーク:脆さから垣間見る美しさ(ミカエル・フェザーズ)

 Javaのテストを支援する、FIT(Framework for Integrated Test)の話。言語はJava。HTMLパーサのシンプルさにちょっと感激。目的を絞れば、これでもいいんだよね。

 肝心のデータ部分は TABLE タグで受け渡ししてるんだけど、著者が強調しているのが、そこでコレクションを使っていない点。二つの参照 parts(最初の下要素)とmore(次要素)だけで、HTMLのツリーを表現しちゃってる。うんうん、とりあえず最初は線形リストだよね。

 この手の芋蔓式リストを作る際、いつも悩むのが、単方向リストか双方向リストかって点。単方向リストの方が実装は楽なんだけど、後で「あの変数はグローバルにしときゃ良かった」的な状態になった時に、双方向だと「リスト手繰ってちょ」をお願いすれば済む、という利点が←そりゃ設計がいい加減すぎ

7章 ビューティフル・テスト(アルベルト・サボイア)

 また出てきた二分探索。単純かつ強力でありながら、意外とバグのないプログラムを作るのが難しい二分探索を例に、JUnitでテスト方法を語ってゆく。

 興味を惹かれたのが、テストしやすさを目的にプログラムを改造している点。昔もデバッグのために printf や perror をアチコチに入れては後でコメントアウトしてたわけで、なら最初から入れときゃいいじゃん、と今になって思ったり。

 なお、ここで披露されるバグは有名なものらしい。再帰的に探索する際、新しい境界値を計算する int mid = (low +
high) / 2
がソレ。high が、int で表現できる最大値近辺だと、オーバーフロー例外を起こす。ここでは姑息な解決法  int mid = (low + high) >>> 1 を紹介してる。しかし、よくこんなバグを見つけたなあ。そしてよく解決法を思いついたなあ。

 ここでは、どんなテストをするか、も読みどころ。よく引っかかるのが境界値テスト。配列や文字列の先頭をゼロで表す言語と1で表す言語を行き来してると、頭が混乱してきたり。ってんで、私は境界値ー1・境界値・境界値+1の三つの値をテストに加える事にしてる。

8章 画像処理のためのその場コード生成(チャールズ・ペゾルド)

 かつての BASIC小僧として、ここは読んでて楽しかった。扱う問題は Microsoft Windows 上の画像処理。一般に画像処理は、各ピクセルに対し××するって感じだ。そのプログラムは、X方向とY方向の二重のループに囲まれてて、こんな感じの処理になる。

for( y=0 ; y<cy ; y++ ) { for( x=0; x<cx ; x++ ) {
if     ( operator==AND ) { ... }
else if( operator==OR  ) { ... }
else if( operator==XOR ) { ... }
} }

 コレのナニが問題かというと、二重ループの中で演算命令 operator を判断する条件分岐がある事。大抵の場合、operator は二重ループの外で値が決まってるんで、ループの中で条件分岐するのは時間の無駄。じゃ、どうするか。

LISP屋「予めループの外でLAMBDA式を変数にして」
チャールズ「うるさい黙れ」
JavaScript青年「予めループの外で無名の関数を…」
チャールズ「うるさい黙れ」
BASIC小僧「予めループの外でPOKEでループ内のマシン語命令を作っとく」
チャールズ「それだ!」

 姑息なw

 だが、Windows が進歩してチャールズ君はピンチに立たされる。かつてはx86系のコードだけを考えればよかったのだが、.NET となりマルチCPUに対応するため、コンパイラは中間コードを吐くようになったのだ。

 だがチャールズ君はめげない。「なら中間コードを作ればいいじゃん」。相変わらず姑息なw

 実際、こういう処理をやってると、「ソコのコンテキストにおける文のカタマリを変数に設定する」みたいな構文が欲しくなったり。いやLISPのLAMBDAやJavaScriptの無名関数って、なんか処理が重そうで、なんか嫌。コンテキストのプシュ・ポップとかやってそうだし。

 と同時に、最近のCPUだと、命令キャッシュの列やパイプラインを乱すんじゃないかなあ、とか余計な心配もあったり。どうなんだろ?

おわりに

 という事で、次の記事に続く。

【関連記事】

|

« Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 1 | トップページ | Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 3 »

パソコン・インターネット」カテゴリの記事

書評:科学/技術」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/201750/60690838

この記事へのトラックバック一覧です: Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 2:

« Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 1 | トップページ | Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 3 »