2005年8月

先日 textfile.orgのほうに書いた「メモ化」に対して、 Hiroto Inabaさんが、Perl版を送ってくださいました。ありがとうございます (Hiroto Inabaさんは、K.Inabaさんとは別の方でした。すみません)。

Hiroto Inabaさんから

「メモ化(memoization), 再帰関数定義関数, 最小不動点」について、メモ化までPerlでやってみました。フィボナッチの定義はちょっと変えました（$fib->(0) == 0)。

use strict;
use warnings "all";

sub fix {
  my ($G) = @_;
  my $f; return $f = $G->(sub { $f->(@_) });
}

sub fixmemo {
  my ($G) = @_;
  my %memo;
  my $f;
  return $f = $G->(sub { return $memo{"@_"} if exists $memo{"@_"};
                         return $memo{"@_"} = $f->(@_);
                       });
}

sub fib_maker { my ($f) = @_;
  sub { my ($n) = @_;
        ($n < 2) ? $n : $f->($n-1) + $f->($n-2);
      };
}

my $t = time;
my $fib = fix(\&fib_maker);
print $fib->(26), "\n";
print "Elapsed: ", time - $t, " sec\n";

$t = time;
my $fibmemo = fixmemo(\&fib_maker);
print $fibmemo->(26), "\n";
print "Elapsed: ", time - $t, " sec\n";

• もともとのK.Inabaさんのエントリ
• textfile.orgに書きかけた結城のPerlプログラム
• nobsunによる、HaskellのMemoise

2005-09-01 加筆

西尾泰和さんから Pythonでメモ化にて、Perlには代入があるんだから結果をキャッシュすればよいだけでは？ という主旨のコメントをいただきました。 はい、その通りです。しかも、 Perlでメモ化をするならMemoizeというモジュールまですでにあります。

2005-09-03 加筆

• id:nabetaniさんのC++版

2004年12月の「スマトラ沖地震・津波」を覚えていますか。 先ほどユニセフのページを見ていて、 最近は思い出していなかったことに気づきました。

2005年4月20日の第20報には、立ち直ろうとしてがんばっている子供たちの姿がたくさん掲載されています。

2005年8月17日の第21報には、長期的復興支援への切り替えについて書かれています。

Windowsで、手早くPerl6で遊ぶ。

1. Jonathan.Worthington @ JWCS.NETへ行って、pugs-win32.zipを入手。展開。

2. コマンドラインから、 pugs examples\mandel.p6 を実行する。

................::::::::::::::::::::::::::::::::::::::::::::................
...........::::::::::::::::::::::::::::::::::::::::::::::::::::::...........
........::::::::::::::::::::::::::::::::::,,,,,,,:::::::::::::::::::........
.....:::::::::::::::::::::::::::::,,,,,,,,,,,,,,,,,,,,,,:::::::::::::::.....
...::::::::::::::::::::::::::,,,,,,,,,,,,;;;!. !!;;;,,,,,,,,:::::::::::::...
:::::::::::::::::::::::::,,,,,,,,,,,,,;;;;!!/>&.|&.!;;;,,,,,,,::::::::::::::
::::::::::::::::::::::,,,,,,,,,,,,,;;;;;!!//)|...|>/!;;;;;,,,,,,::::::::::::
::::::::::::::::::,,,,,,,,,,,,;;;;;;!!!!//>|.......|//!!;;;;;,,,,,::::::::::
:::::::::::::::,,,,,,,,,,;;;;;;;!!/>>I>>)||I...... &))>////.!;;,,,,:::::::::
::::::::::,,,,,,,,,,;;;;;;;;;!!!!/> ...................I ..../;;,,,,::::::::
::::::,,,,,,,,,;;;;;!!!!!!!!!!//>|. .......................I>!!;;,,,,:::::::
:::,,,,,,,,,;;;;!/||>///>>///>>)| ..........................|&/;;,,,,,::::::
:,,,,,,,,;;;;;!!//)&...I.. .&||&.............................)/!;;,,,,,:::::
,,,,,,;;;;;!!!//>)I .........................................&!!;;,,,,,:::::
,;;;;!!!!!///>) ............................................)/!;;;,,,,,:::::
..........................................................&)/!!;;;,,,,,:::::
,;;;;!!!!!///>) ............................................)/!;;;,,,,,:::::
,,,,,,;;;;;!!!//>)I .........................................&!!;;,,,,,:::::
:,,,,,,,,;;;;;!!//)&...I.. .&||&.............................)/!;;,,,,,:::::
:::,,,,,,,,,;;;;!/||>///>>///>>)| ..........................|&/;;,,,,,::::::
::::::,,,,,,,,,;;;;;!!!!!!!!!!//>|. .......................I>!!;;,,,,:::::::
::::::::::,,,,,,,,,,;;;;;;;;;!!!!/> ...................I ..../;;,,,,::::::::
:::::::::::::::,,,,,,,,,,;;;;;;;!!/>>I>>)||I...... &))>////.!;;,,,,:::::::::
::::::::::::::::::,,,,,,,,,,,,;;;;;;!!!!//>|.......|//!!;;;;;,,,,,::::::::::
::::::::::::::::::::::,,,,,,,,,,,,,;;;;;!!//)|...|>/!;;;;;,,,,,,::::::::::::
:::::::::::::::::::::::::,,,,,,,,,,,,,;;;;!!/>&.|&.!;;;,,,,,,,::::::::::::::
...::::::::::::::::::::::::::,,,,,,,,,,,,;;;!. !!;;;,,,,,,,,:::::::::::::...
.....:::::::::::::::::::::::::::::,,,,,,,,,,,,,,,,,,,,,,:::::::::::::::.....
........::::::::::::::::::::::::::::::::::,,,,,,,:::::::::::::::::::........
...........::::::::::::::::::::::::::::::::::::::::::::::::::::::...........
................::::::::::::::::::::::::::::::::::::::::::::................

3. コマンドラインから dir /s /b /p *.p6 と打ち、面白そうなPerl6のスクリプトをのぞいて見る。 dir /s /b /p *.pl でもよい。

4. docsディレクトリに行って、ドキュメントを眺めてみる。

Enjoy!

今日も楽しく原稿を書く。というか、実際の作業としてはどんどん削っているんだけれど。

プログラムでも文章でも、たくさん書いていると自分の中に「こう書くとよい」というイメージができてくる。 でもそれをtips・虎の巻・作法という形でまとめると、ずいぶん違ったものになってしまう。 つまり、実例から離れてまとめてしまうと、何かしら大事なものが失われてしまうのだ。

プログラミングでも、文章書きでも、自分が直面している「まさにその場」でどう判断するかが問われる。

何をどう書き、何をどう削るか。 どこを膨らませ、どこを捨てるか。

ある程度は、本や他の人から学ぶことができる。 Google先生に聞くのもよいし、隣の誰かからアドバイスをもらってもよい。

でも、それだけでは絶対だめだ。 自分の心で感じ、自分の頭で考え、 自分の手を動かさなければうまくいかない「何か」が必ず残る。

だから難しく、だから面白い。

『人月の神話』第3章を読んでいる。

人を投入すればよいというものではないが、少数精鋭チームでは時間がかかりすぎる。 それに対するミルズの案は、大規模な仕事の各セグメントに「外科手術チーム」で取り組む、というもの。

外科手術チームというのは、 たった一人の執刀医（チーフプログラマ）がデザイン・コーディング・テスト・ドキュメント書きを行なう。 他のメンバ（副執刀医・管理者・編集者・プログラム事務係り・ツール製作者・テスト担当者・言語エキスパート） は執刀医を助ける専門的な役割を担う。

「意思決定はたった一人が行う」と「メンバの役割は特化されている」とがポイント。

• 『人月の神話 ―― 狼人間を撃つ銀の弾はない 』Frederick Phillips,Jr. Brooks

過去1年のPOPFile。

分類されたメール数:  76,550
分類エラーの数:         141
精度:                    99.81%

分類されたメール数
バケツ        分類数           誤検出  見逃し
spam          44,776 (58.49%)      14     113
work          31,259 (40.83%)      19      28
unclassified     515 (0.67%)      108

• POPFile
• POPFile（日本語）

今日も楽しく原稿を書く。

これまでに書いた分を読み直し、書き直す。 書いているうちに必要な図のイメージがわいてきたので描く。

今日も楽しく原稿を書く。

おととい書いた分を読み返す。気になった部分をほんの少し直す。昨日よりは直す量が少ない。 昨日書いた分も読み返す。少し書き換え発生。 ずいぶん以前に作った図を見直して、少し追加修正。 原稿ファイルの下に積もっていた「これも書かなきゃねリスト」を原稿のあちこちに移動する。

そんな風に仕事をしていると、二時間くらいはあっという間に経ってしまう。 楽しい。

ブラウザの起動時間、Visioの起動時間、コンパイルの待ち時間の間に「ながら運動」をする。 プログラマのダイエット・エピソード2である。

今日も楽しく原稿を書く。

昨日書いた分をていねいに読み直して、 あちこち直す。図を調整する。 そして今日の分をざくざくと書く。

第2章を読んでいる。人月はなぜ神話か。 以下、引用（強調は著者）。

コストは実際に人数と月数の積に比例する。 が、進捗はそうではない。 したがって、仕事の大きさを測る単位としての人月は、疑うべき危険な神話なのだ。 人月とは、人と月とが互いに交換できるという意味だからである。

そしてこの後に、 女性がたくさん動員されても子供が一人生まれるまでにかかる時間は短くならない という話が続く。

• 『人月の神話 ―― 狼人間を撃つ銀の弾はない 』Frederick Phillips,Jr. Brooks

以下は、読みながら考えたこと。

プログラマは大きなクラスをリファクタして、小さなクラスに分ける。 大きなクラスはたくさんの責務を抱え込みがちだからだ。 リファクタリングを繰り返し(Refactor, Green)、風通しをよくすれば、いやな臭い（リファクタリング用語）も少なくなる。

では、その類推から、 一人の人がたくさんの責務を抱えてしまうとよろしくないからといって、 複数人に仕事を分けることは妥当だろうか。

きっと、場合による。

慎重に責務が分解され、 相互のインタフェースがきちんと定まっており、 各人が自分の責務をちゃんと果たせるなら、妥当だろう。

しかも、（一度の責務の分解でベストな状態になるとは思えないから） 再度リファクタしても各人のモティベーションが下がらないなら(Refactor, Green?)。 しかし、そういうことはかなり望み薄だ。 人数が少なく、各人の能力とコミュニケーション力が高いなら、うまくいく可能性は高い。

「大規模なソフトウェア」をリファクタリングすることよりも、 「大規模なソフトウェアの開発プロセス」をうまくリファクタリングすることのほうがずっと難しそうだ。

大規模なソフトウェアの開発は、とてもとても複雑な問題であり、 人間はそれを解く方法を見つけていない（狼人間を撃つ銀の弾はない）というのは、 心に刻んでおく必要がある。

（でも、その一方で、「これが銀の弾かも」と思うことが 一時的にモティベーションを上げる場合がありそうな……でもそれはまた別の話）

今日も楽しく原稿を書くお仕事。 私は文章を書くと元気になってくる。

特に「分量に糸目はつけないから、好きなだけゆっくり、好きなだけていねいに書いてごらん」と言われて書くのがよいみたい （言われて、といっても自分で自分に言うんですけれどね）。 そうやって、むちゃくちゃ長い説明文をいったん書いた上で、それを自分で読み直して短くしていく。 それがまた楽しい。きちんと段階を経るのが大切のようだ。

最初から短い文章を書くのは難しいし、ストレスもかかる。 ストレスの理由ははっきりしている。 いったん長い説明文を自分向けに書かないと 自分がほんとうに分かっているかどうか確認できないからなのだ。 自分が分かっていないことを人に説明することはできない。

話を整理しよう。説明文を書くには、2つのフェーズがある。

第1のフェーズは「自分の理解」だ。 ある事柄について、自分が十分に納得いくほどていねいな説明文を書けたなら、 私は自分で「わかった」といえる。 その場合、文章の長さはいくら長くてもよい。とにかく首尾一貫していること。 そして、あいまいなところや、「わかったふり」をしたところがない文章を書けたかどうかが重要。

ここで、帽子をかぶりなおす。

第2のフェーズは「他者への説明」だ。 自分の理解をそのまま他者に押し付けることはできない。 順序を変え、例を吟味し、無駄を省き、短くしていく。 その文章を読んでいる他者をイメージしながら（相手のことを考えながら）、校正を繰り返す。 このようにして練り上げた文章ができたなら、他者にうまく説明できる状態になったといえる。

最初から短い文章を書くのは、この2つのフェーズを一気にやることになる。 それはとても難しい。

※補足：上記の2つのフェーズはマクロスコーピックな視点になっていることに注意。 ミクロスコーピックに見れば、文章を書いている最中は上記の2つのフェーズを細かく行き来している部分もある。 小さなイテレーションを繰り返す開発のように。

• 文章を書く心がけ
• 文章教室(投稿・添削は休止中です)

もうすぐ秋。秋は勉強の季節。 基本を大切に、ということで『人月の神話』など読み始める。 実は未読だったのだ。

• 『人月の神話 ―― 狼人間を撃つ銀の弾はない 』Frederick Phillips,Jr. Brooks

序文は「Soli Deo gloria ―― 神にのみ栄光あれ」で結ばれていた。

月曜の朝。

空を飛びたくてたまらない小鳥のような気持ちで、仕事をはじめよう。

プログラマのダイエット・エピソード2が、 delphierさんのプログラムの性能向上のきっかけになったらしい (^_^;

• DevPartner Profiler Community Editionは性能分析に大いに役立った（delphierさん）

Javaのジェネリクスに関するクイズ、その二。

Listインタフェースを実装しているクラスなら、ArrayListであっても、LinkedListであっても、 Vectorであっても表示できる便利なユーティリティクラスとして、 Utilというクラスを宣言した。

import java.util.List;

public class Util {
    public static void printList(List<Object> list) {
        for (Object obj : list) {
            System.out.println(obj);
        }
    }
}

でも、これはあまり便利なクラスにはならなかった。なぜか。

• Generics in the Java Programming Language (PDF)
• 参考: The Java Tutorial

Javaのジェネリクスに関するクイズ。

java.util.ArrayListクラスは、 java.util.Listインタフェースを実装しているコレクションクラスである。

ここで、

List<String> list = new ArrayList<String>();

は、問題なくコンパイル＆実行できる。

しかし、

ArrayList<Object> list = new ArrayList<String>();

は、コンパイルエラーになる。この理由（言語仕様としての合理性）は何か。

※要素の型に関するIS-A関係を、コレクションの型に関するIS-A関係に拡張しないようにした理由は何か。

• id:kmoriさんの解答

PB memoの シミュレータのテスト・デバッグを読んでいて「テストが困難な性質」について考えた。 例を挙げる（下に行くほど困難）。

• 1. 正しい画面表示が行なわれているか(GUI)
• 2. 正しく現象をシミュレートしているか
• 3. スレッドセーフか
• 4. セキュアか

これらの性質はテストが困難だと思う。 なぜだろう。 しかも困ったことに、これらの性質を持つソフトウェアは、作ること自体が難しい。

以下、続きの話。

• テスト困難な性質(PB memo)

確かに、 どんな挙動が正解かが分からない、 明確に記述することが困難、 となるとテストをするのは難しくなりますね。

プログラマのダイエットはたいへん効果があった。 けれど、最近ずっとさぼっていたので、元の木阿弥状態。 うう。 そこで、プログラマのダイエット・エピソード2をはじめることにした。

プログラマのダイエット・エピソード2とは何か。

ポイントは4つある。

• 鉄則1. 計測ツールを使え
• 鉄則2. やたらに直すな（主要因を見極めてから直せ）
• 鉄則3. 度を越した改善を約束するな

ここまでは、これまでのプログラマのダイエットでも使ってきた。 これに、次の鉄則4を加えることにした。

• 鉄則4. ロングテールを生かせ

eコマースでは、ロングテールが重要な役目を持つ。 売上金額の商品別分布を見ると、販売数が少ない商品（つまり非ベストセラー商品）の合計が多くの割合を占めるという（長いすそ野の合計だ）。 この発想を、体脂肪率の減少とカロリー消費に当てはめてみる。 ベストセラー商品に対応するのは、週に何回か運動の日を設けスポーツクラブにいったりすることだ。 すなわち、まとめてどかっと処理するやり方。 ロングテールに対応するのは、毎日（いや、毎時間）ほんのちょっとずつ筋肉刺激するような運動をするやり方。 コンピュータに向かいながら、本を読みながらの「ながら運動」である。 頻繁にストレッチしたりするのもよい。

…という発想のヒントは『実践！日常ながら運動ダイエット』という本から得ました。 （ロングテールに関連付けたのは私ですけれど(^_^;）。

この本は読みやすくてなかなかよい。 男性が運動するというと、腹筋・スクワット・腕立て伏せというイメージがある。 でも大変だから続かない。 この本の中では、腹筋・スクワット・腕立て伏せをそれぞれLightWeightにして Iterativeに継続するための方法も書かれている。

さて、どうなるかな。

• 『実践！日常ながら運動ダイエット』長野茂著

たとえば、 Knuth先生の『The Art of Computer Programming Volume 1 日本語版』の、p.184〜186などはいかがでしょう。 Knuth先生が「複雑で長いプログラムを書くにはどうすればいいのか」について考察しています。

• ステップ0 (最初のアイディア)
• ステップ1 (プログラムのおおまかな下書き)
• ステップ2 (最初の動くプログラム)
• ステップ3 (再検討)
• ステップ4 (デバッグ)

さらっと読むと当たり前のことが書かれているようですけれど、 なかなか含蓄のあることが書かれている数ページだと思います。

トップダウン、ボトムアップ、リファクタリング、反復的な開発、 静的な検討と動的な（実行時の）検討、テストデータとデバッグ用のコード、 そしてバグの記録。 …現代的な用語でいえばそういうトピックが詰まった数ページですね。

• The Art of Computer Programming Volume 1 日本語版 Fundamental Algorithms Third Edition

Perlクイズを久しぶりに発行。

• 結城浩の『Perlクイズ』
• 結城浩の『Perlクイズ』2005-08-16 No.0086

夕食後、ソファに座って息子たちに絵本『壺の中』を読む。

前から気になっていたのだけれど、実はこの話、階乗の話ではない。 なぜなら、最後に壺が10個出てくるが、 その次には11個の国が出てくるわけではなく、 1個の国が出てくると思われるからだ。

• 『壺の中』安野雅一郎・安野光雅

ぼぼるパパの「進化論対ID」の話。 とても分かりやすく興味深い話なので、ぜひみなさんもお読みください。

• 進化論対ID（はちことぼぼるの日記）

何だか一年中、忙しい忙しいと言ってるみたいでちょっと恥ずかしいけれど、忙しいなあ。

奥さんに「忙しいなあ」というと、間髪入れず「でも楽しそうに見えるよ」と言われてしまう。

確かに、楽しんでいるのですけれどね。

私「この間、電車かどこかの広告で見たクイズなんだけど」

長男「うん、何？」

私「私の家は駅から4kmあります。友達の家は私の家から3kmあります。それで…」

長男「それで、友達の家は駅から何kmあるかっていう問題？」

私「まあね。問題は、友達の家は駅からどれだけの距離にある可能性があるか、その範囲を示せ」

長男「簡単じゃん」

私「そう？」

長男「要するに三角形ができるかどうかだよね？」

私「ふむふむ」

長男「4kmと3kmなんだから、両方を足したよりも大きくはなれない。いや、両方足した以上になれないんだな。だから7km未満。でしょ？」

私「頭の回転が早いな。でも惜しい」

長男「惜しい？」

私「三角形になる条件を考えたのは正しい。でもこの問題の場合は駅・私・友達が一直線に並んでもよい。だから7km以下。未満じゃなくね」

長男「そうか…」

私「それに、あなたは上だけを押さえたけれど、それも正しくない」

長男「上を押さえる？」

私「あー、ええと、7kmより遠くならないという上限だけを示したけれど、下限もあるんだ」

長男「うーん、そう？」

私「駅・友達・私という順番に並ぶ場合だね。この場合は駅と友達の家の距離は1kmになる。これ以上短くはならない」

長男「そうか、そうだね！」

私「というわけで答えは、『1km以上、7km以下』です」

長男「ふむふむ」

私「もっとも、電車の広告では何個か候補が並んでいて『この距離になる場合はあるでしょうか』だったけれどね」

* * *

ここから一歩先に進むと「長さa, b, c ＞ 0 の線分が三角形を作れる必要十分条件は何か？」になります。 ええと、三角不等式って言うんでしたっけか。 そして今度は、そのような不等式を満たす概念として、空間に「距離を入れる」ことができるんですよね？

結城は、集合に「位相を入れる」とか「距離を入れる」という考え方がすごく好きです。 Perlで、単なるリファレンスをblessしてオブジェクトにするのと似ていませんか？

結城が 『パターン指向リファクタリング入門』無料プレゼントのお知らせで書いた「例」に対して、artonさんが、 読者像もきちんと想定できるってことなんだろうと反応してくださっていたのに気がつきました。 調べてみたところ、応募総数29人のうち約3名はあの例と重なる部分が多い方だったようです。 「例がほとんどテンプレートになっています」という主旨のことを書いてくださった方も一人いらっしゃいました。

『パターン指向リファクタリング入門』の 無料プレゼントの抽選を行ないました。 当選した方には、個別に当選のお知らせと住所確認のメールをお送りしました。

当選なさらなかった方、 せっかく応募してくださったのにすみませんでした。

応募数は29名でした。 たくさんのご応募と応援メッセージをありがとうございます。

『パターン指向リファクタリング入門』の 無料プレゼントの〆切は今日(8/5)です。 現在、応募数は25名です。

『パターン指向リファクタリング入門』の 無料プレゼントの〆切は明日(8/5)です。 現在のところ、応募数は14名です。

いつの間にか8月になっていました。 月初めにはよく、日記やtextfile.orgがNot Foundになってしまうミスをする。 200508.htmlのようなHTMLファイルは自動的に作るのだけれど、 このファイルをサーバに転送するための設定ファイルが自動的に更新されないからだ。

なかなか腰を落ち着けて日記を書く時間がとれない。 といいつつ、昔のコンテンツをぱらぱら読んで楽しんでいる。 昔の自分の文章に励まされたりして。

「日記ダイジェスト」は、いつの間にか大量になっていますね…。 読み始めると、時間がどんどん経ってしまう。 ダイジェスト・ダイジェストもしくはカテゴリ分けが必要みたいです。 (^_^;

風船（メリークリスマス）のような文章って、そのときにしか書けない文章ですよね。

• 日記ダイジェスト
• いまを生きる
• 「OOエンジニアの輪！」第25回 結城浩さんの巻