2006年5月

数日中断していた作業を継続しようと思ったけれど、 中断前にどこまで進んでいたか、まったく覚えていなかった。 覚えていることは、その作業に自分が与えたプロジェクトコード(数文字からなる英文字列)だけである。

でも、あわてないあわてない。 おもむろにプロジェクトコードをコマンドプロンプトで入力する。 実はプロジェクトコード名はバッチファイル名にもなっていて、 それを実行すると、そのプロジェクトの作業ディレクトリに移動するのだ。 すると、そこに自分の作業ログファイルが置かれている(このファイルはSubversionで管理されている)。 そこでその作業ログファイルを読む。数日前に私が作業中断前に書いたログが残っている。 数日前の私からのお手紙（引き継ぎ資料）である。 それをふむふむと読みながら「Good Job! よくぞきちんとログを残しておいてくれたね」と数日前の私に感謝する。

つまり、私が「記憶」しておくべきことはプロジェクトコードだけだ。 あとは作業ログファイルが雑多な情報をすべて代わりに記憶しておいてくれる。

こういう仕事の仕方をしていると、 自分の記憶力が衰えることはこわくなくなる（つまり、自己の能力に対する不安がなくなる）。 また、ちょっとした細切れ時間であってもそれなりに仕事を進めることができるから、 たくさんの仕事を並行して処理することもおっくうじゃなくなる （ちょうど、将棋の多面指し(っていうんでしたっけ)をしているような感じ）。 さらに、一つの仕事をしているときに、他の仕事が気にならなくなる （つまり、現在に集中できる）。

そこで大事なのは「作業ログの書き方」になるわけですが、 細かいテクニックはさておき、最重要ポイントを「たった一つだけ」押さえましょう（ってなぜに講義調）。 それは…

作業ログを書くための最重要ポイント：自分の頭の中に情報を残さない

「自分の頭の中に情報を残さない」と心がけて作業ログを書くのが良いです。 ええ、もちろん自分の頭の情報をぜんぶ書くなんて不可能なことは承知です。 でも、たいていの場合は自分の頭に情報を残しすぎ。つまり作業ログに書き足りない点があるんです。 たとえば「次に何をやろうとぼんやり考えていたか」の「ぼんやり」の部分。 「これはやっちゃだめだな」や「あのことは早めにすまそう」といった心づもり。 そういう「うまく表現できないけれど大切なこと」こそ、作業ログに落とすのです。 不完全でもよいです。 そのような心がけを「自分の頭の中に情報を残さない」と表現するのは適切だと結城は思います。

お試しあれ。

• 作業から離れる前にすべきこと
• 過去の自分と協力して、未来の自分へ仕事を託す
• 勉強日記の書き方

追記：上で述べた「プロジェクトコード名に対応するバッチファイル」は自動生成しています。以下でそのスクリプト(hereという名前)を公開しています。ご参考に。

• here:「ここにあとで来る」ためのバッチファイルを作るスクリプト

追記：s/多面差し/多面指し/の修正をしました。miwakoさんありがとうございます。

私の「プログラミング言語の勉強日記」は以下にあります。

• Rubyの勉強 - rubyco（るびこ）の日記
• Schemeの勉強 - 結城浩のSICP日記
• Haskellの勉強 - 結城浩のHaskell日記

SchemeとHaskellに関しては「はてなグループ」を利用しています。 先日、両方とも「オープン」という設定にしましたので、 「Schemeの勉強日記を書いてみよう」とか「この機会にHaskellやってみるか」という方は、 よろしければご利用ください。 はてなユーザならすぐに書き始められます。 結城の承認を待つこともありません。

• sicpグループ ―― プログラミング言語Schemeの日記やSICPの勉強日記を書きたい人のためのグループです。
• haskellグループ ―― プログラミング言語Haskellの日記を書きたい人のためのグループです。

ちなみに、はてなダイアリーやはてなグループの日記を気軽に更新するには、 拙作「はてなダイアリーライター」が非常に便利です。 これがなかったら、結城は絶対に上のような複数日記をメンテナンスしようとは思わなかったでしょう。

• はてなダイアリーライター

なお、蛇足ですが、一言。 もともと結城は、 はてなグループを利用して自分の勉強日記を書くというだけのつもりでg:sicpやg:haskellを作りました。 でも、巡り合わせによって「私一人だけで使うのではなく、みんなで楽しく勉強する場」として公開する運びとなりました (楽しい巡り合わせです。babieさん、ありがとう！)。 ですから、すでに存在するSchemeやHaskellのコミュニティというものを軽視する意図はまったくありません。 そういう誤解をする人は少ないとは思いますが、念のため書いておきます。

では、楽しんでプログラミング言語を勉強しましょう。

Enjoy!

今日は日曜日。 朝、雨のせいか、みんな寝坊。 あわてて用意をして教会にゴー。

午後から奥さんは用事があって出かけ、 わたしと子供たちでお留守番。

Danさんのblogで紹介されて気になっていた 「たけしのコマネチ大学数学科」をビデオでやっと見た。 ケプラー予想の回とヨセフスの問題の回。 なかなかおもしろかった。 ヨセフスの問題で、長男は、 二の累乗が関連していることまでは気づいたようだった。 もっとも「これって継子立て？」と言っていたから、知識としても知っていたのかもしれない。 ヨセフスの問題は『コンピュータの数学』にも例題として載っていましたね。

その後お昼寝（というか、午後寝）。 に入ったとたん、奥さんから電話で起こされる。 不機嫌な応対でごめんなさい。 眠かったんだよう。

そうそう、ソフトバンククリエイティブの編集さんから 『ふつうのHaskellプログラミング』（愛称「ふつける」） をご献本いただいた。 ありがとうございます。 というわけで、夕方から青木さんの「ふつける」を読みながらHaskellのお勉強。 はてなのg:haskellで日記も立ち上げる。

babieさんの「haskellって一般的な名前のグループを一人で使うのはどうよ」という話題があり、 なるほど、それもそうかな、ということで「haskellグループの運営について考えました」というエントリを書く。 このあたりは深めるといろんな話題に発展しそうだけれど、 それをやっていると肝心の勉強が進まないので、まずは現実的な宣言をして、次に進む。 （2006-05-29追記：他の人も参加できるようにしました）

晩ご飯はピザ。

夜中になって少し仕事をする。 途中で、昔の連載記事に大バグがあったのではないかと気がつき、 あわてて検証する。私の勘違いであることがわかって、ほっと一息。

• 『コンピュータの数学』（アマゾン）
• 『ふつうのHaskellプログラミング』（アマゾン）
• 『ふつうのHaskellプログラミング』（青木さんのサポートページ）
• 結城浩のHaskell日記
• haskellグループの運営について考えました
• haskellグループの運営について、もっと考えました

多忙なりね。

それはさておき、 文章を書くというのはとても勉強になるものですね。 というテーマは頻繁にこの日記に出てきます。 自分が勉強したことを、blogでも日記でも 連載記事でも本でもいいから「文章」という形で書いてみる。 自分の言葉で、他の人に説明してみる。 そうすると、とてもとても理解が深まる。

このたび、日経ソフトウエア誌で 「簡単実装で学ぶWeb技術2006」 という新連載を始めることになりました。 第一回（2006年5月24日発売予定）は「Ajax」です。 簡単なサンプルを通してWeb技術をおさらいしましょう。 応援よろしくお願いいたします（ぺこり）。

• 日経ソフトウエア
• 「簡単実装で学ぶWeb技術2006」

ちなみに第二回目は「はてな認証API」を予定しています。

あ、誤植発見。

『The Art of Computer Programming Volume 3 Sorting and Searching Second Edition 日本語版』のp.363。「けえども」は「けれども」の誤植。

今日、ある方々にファイル群をzipしてメールに添付して送ったのだけれど、 肝心のファイルがzipされていなかったという失敗をしてしまった。 その原因は、エディタの排他制御の設定のせい。 エディタで開いたままzipを動かしてしまい、 zipはそのファイルをオープンできずにスキップしていたらしい。

声のかけら。やYukiWikiにspamが大量に。 削除してくださった方、ありがとうございます。 適宜、キーワードによる拒否をしているんですけれど、追いつきませんね。 いま忙しくて対策に時間をかけられません。うう。

あ、誤植発見。

『The Art of Computer Programming Volume 3 Sorting and Searching Second Edition 日本語版』のp.198。「Dogson」は「Dodgson」の誤植(二カ所)。

(原書は間違っていない)

水曜日も淡々と（もういいって）。 今日はTociyukiさんのJSON::Hatchetで遊んでいました。 これ、他のモジュールに依存していないのが手軽でいいですね。

download, gunzip, tar xvf, cd, perl Makefile.PL, nmake, nmake test, nmake install, perldoc JSON::Hatchet, ふむふむ。

それからJSONを手書きして、JSON::Hatchet->newして、deserializeして、Data::Dumperして、自分の理解が正しいことを確認。

• JSON::Hatchet 0.002 JSONパーサ

hatchetは「手斧」という意味のようです。

午前中はここまで。 svn commitしてバックアップとってからお昼ごはん。

火曜日も淡々と仕事。あ、でも今日はちょっと盛り上がった。 昨日の設計を元にプログラムを作ろうとしたけれど、 そのまえに画面を整えようと思い、HTML::Templateとたわむれる。 こういうときに、以前の「声のかけら。」での経験が役に立つ。 過去に自分が書いたスクリプトが自分の勉強の記録になっていて、 後からそれを再利用できるのはうれしいものですね。自分の財産。

ローカルでCGIのテストをしていて、 ブラウザのキャッシュがじゃまでしょうがなかった。 リロードしても再実行してくれないことがあるから。 でも、

print $q->header(-expires => 'now');

しておけばよいことに気づいた。 気づいたというか、perldoc CGIでcacheをさがして見つけたんですけれどね。

CGI作るのってどうしてこんなに楽しいんだろうなあ。

午前中はここまで。svn commitしてバックアップとってから本屋ちゃん本屋さんへ。

月曜日は淡々と仕事。連載の原稿を書く。 というか、原稿を書くためのプログラムを書くための設計をするためのメモを書く。 「書いて考える」っていいなあ。

ところで、最近Webで勉強するのが楽しいです。

• rubyco（るびこ）の日記 … Rubyのお勉強
• 結城浩のSICP日記 … Schemeのお勉強

金曜日も淡々と仕事。 昨日の続きで、あまり構成・校正のことを考えずに、 メモをタイプタイプ。 そして心の中から出てきた何かも合わせてタイプタイプ。 前のめりにつっぱしるようにタイプタイプ。 タイプタイプ。

…1時間ほどタイプタイプしたら、 一息入れてPDFに変換して眺めてみる。 ふむふむ。おもしろい。 自分の頭の中にあったもやっとしたものを、 あらためて文字として見るのはたのしいものですね。

さっと記録するには紙と鉛筆がいいけれど、 編集したり、並べ替えて眺めたりするにはコンピュータに入れるのが最適だ。

論理のねじれや、文章のゆがみはたくさんあるけれど、 とりあえず、今日の分、 自分が考えていたことは外にはき出され、記録された。 そうすれば、忘却や紛失をおそれることなく、検討に入ることができる。 忘れないようにしようと気持ちを張っている必要はもうない。 頭をかちっと切り換えて（ぼうしをかぶり直して）、 読者のつもりになって読むことができる。

今日も今日とて淡々と仕事。 どうせ後でばりばり書き直すことになるのだろうけれど、 まずはやってみるかと思い、 とある本の最初の章をいきなり書き始める。

書き進めると、 いつものように自分が知らないことがたくさんあるのに気づく。 きちんと文章として書くためには、 しっかりした土台と、 ゆらがない骨組みが必要になるのだが、 現在その準備がまったく出来ていないことに気がつく。

やれやれ、と思いつつも、 次に調べるべきことが具体的にはっきりするのはありがたい。 準備が整ってから書き始めるというよりも、 書いているうちに、 本当に準備すべきものが何であるか、 次第にわかってくる、というほうが現実に近い。

もしかしたら、きちんと準備ができた状態というのは、 本を書き終えた状態のことではないか。

ここはこうする。あそこはああする。 こっちはこれでよい。 何かを作り上げるというのは、 そのような細かな判断や意志決定の積み重ねの結果だろう。 ということは、すべてが決まった時点というのは完成した時点だ。

…などと当たり前のことを考えつつ、 心に浮かんだことをざくざく書いていく。

相変わらず淡々と仕事。 とある本のはじめの章の題材を練る。 すでにノートに手書きしていたメモを機械的にタイプする。 でも「機械的に」というのは自分を仕事に向かわせるために使っている便法であって、 実際にやっていることはまったく機械的ではない。

ノートを読みながらタイプしていると、 心にはいろんなことが自然に浮かぶ。 浮かび上がってきた「輝く何か」を両手ですくい上げ、 傍らに置いてある水槽にそっと放す。 台無しにしないように気をつけてファイルに記録するのだ。 そんな風にノートのメモ書きをタイプしおえたら、 水槽は美しい何かでいっぱいになっている。 形はまだ定まっていないのだけれど、 この中から何か素敵なものが形作られてくることは確信している。 そんな水槽を抱えて、家に帰る。

月曜日は淡々と仕事。 とある本の最終章の題材を練る。 書きながら考えるって大切。 頭の中だけで考えたほうが速いことは速いのだけれど、道筋が残らない。 だから、現在考えていることを数日後に頭の中に再ロードするのは非常に困難。 記録を残しながら考えると、スピードは非常に遅くなるけれど、 数日後に「続き」を考えることができる。 だからトータルとしての生産性は、記録を残しながら考えたほうがはるかに高くなる。

先日、所用があって実家に帰った。 姉も実家に来ており、いっしょに茶の間でお茶を飲んでおしゃべりをしていた。

そこに父親が書斎から出てきて、 姉に「この問題、解答が間違っていると思うんだが…」と話しかける。 見ると、三角関数の問題。 なんでも、父が塾で教えている高校生が持ってきた問題とのこと。 父が解き直してみると、解答と違う値になったらしい。

姉は、父の説明を聞きながら、ふんふん…と確かめ、 父の値のほうが正しいと結論を出す。父は嬉しそう。

しかし…高校生の数学の問題を解く父も大したものだけれど、 お茶を飲んでいるときにsin, cosが出てきてもまったく動じない姉もすごいと思う。

おねえちゃん、かっこいい。

Knuth先生の 『The Art of Computer Programming, Volume 4, Fascicle 4: Generating All Trees -- History of Combinatorial Generation』を調べていて不思議なことを発見。

• 1-201-85394-9 : 本に書かれているISBN
• 0321335708 : amazon.co.jp, amazon.comで表示されているISBN

なぜ違う？

追記：

わかりました！

私が見ている本が間違っていた……ようです。 「0-201-85394-9だとFascicle 3になりますね」と教えてくれた読者さん、ありがとうございます。ああ恥ずかしい。

• The Art of Computer Programming, Volume 4, Fascicle 3: Generating All Combinations And Partitions

さらに追記：

「本とサイトでISBNが違う件」は「結城の見間違い」でいちおう解決しました。 しかし、複数の読者さんから指摘があった、 「1-201-85394-9ではチェックディジットが合わない件」はまだ解決していませんでした。

もう少しちゃんと書きます。 The Art of Computer Programming, Volume x, Fascicle yを VxFyと略記することにしますと、以下のように整理できます。

• V4F2: 本には ISBN 0-201-85393-0 とあり、amazon.co.jpでは 0201853930 (一致)
• V4F3: 本には ISBN 1-201-85394-9 とあり、amazon.co.jpでは 0201853949 (最初の一桁が一致していない)
• V4F4: 本には ISBN 0-321-33570-8 とあり、amazon.co.jpでは 0321335708 (一致)

(誤り)ISBNの最初の9桁をベクトルだと考え、 (10, 9, 8, 7, 6, 5, 4, 3, 2)というベクトルとの内積をmod 11した結果は ISBNの最後の1桁(10ならばX)になるらしいです。

(修正)ISBNの最初の9桁をベクトルだと考え、 (10, 9, 8, 7, 6, 5, 4, 3, 2)というベクトルとの内積をmod 11した結果を、 11から引いてmod 11した値は、ISBNの最後の1桁(10ならばX)になるらしいです。 ということからすると、V4F3の本に書いてあるISBNは誤っているようですね。

というわけで結論は以下です。

• 結城はV4F3の本とV4F4のサイトを見て「なぜ違う？」と騒いでいた。違って当然。違う本だから。
• でもそれはそれとして、V4F3の本に書かれているISBNはたまたま誤っているようである。

• Google: ISBN
• Wikipedia: ISBN
• U.S. ISBN Agency

またまた追記

[備]ISBNのチェックデジットで、 結城の計算式が誤っていたことを教えていただいたので、上の記事を修正しました。 感謝します。

use strict;

my @isbn = qw(
    4797331623
    4797329734
    4797327030
    4844319159
    4797322977
    4797321261
    479730507X
    4797305819
    4797307579
    489052519X
    4890528687
);

my @check = ('0'..'9', 'X');

for my $isbn (@isbn) {
    my @digits = $isbn =~ /\d|X$/g;
    my $sum = 0;
    for my $i (0..8) {
        $sum += $digits[$i] * (10 - $i);
    }
    my $check = $check[(11 - ($sum % 11)) % 11];
    if ($digits[9] eq $check) {
        print "$isbn OK\n";
    } else {
        print "$isbn NG: \$check = $check\n";
    }
}

チェックするだけならこれでもよいか。

ISBN全体をベクトルだと考え、 (10, 9, 8, 7, 6, 5, 4, 3, 2, 1) というベクトルとの内積をmod 11した結果は0になる (ISBNの最後の1桁がXならばその桁は10と見なす)。

use strict;

my @isbn = qw(
    4797331623
    4797329734
    4797327030
    4844319159
    4797322977
    4797321261
    479730507X
    4797305819
    4797307579
    489052519X
    4890528687
);

my %value = map { $_ => $_ } (0..9);
$value{'X'} = 10;

for my $isbn (@isbn) {
    my @chars = $isbn =~ /\d|X$/g;
    my $sum = 0;
    my $weight = 10;
    for (@chars) {
        $sum += $value{$_} * $weight;
        $weight--;
    }
    if ($sum % 11 == 0) {
        print "$isbn OK\n";
    } else {
        print "$isbn NG\n";
    }
}

月曜日は淡々と仕事。 新しい本（ええと、次の本か、次の次の本か、その次の本かは不明ですが）の目次をもう一度練る。 普段から書きためていたノートを見て、タイプし直す。 タイプしながら少しずつ内容をふくらませてみる。 はじめは思い切り、何でもかんでも入れてみる。 そうしているうちにだんだん方向性が見えてくる（はず）なので、今度は絞り込む。 最近は「何を入れるか」よりも「何を削るか」が大事ということがわかってきたので、ていねいに読み返してばっさりと。 でも、自分の気持ちを納得させるためにバージョン管理はしておく。 「いまばっさり削っても、バージョン管理しているからいざとなれば昔に戻せるんだよ」と自分に言い聞かせて、削る。 でもいままで、いったん削ったのをバージョン管理で戻したことはないんですけれどね :-P 自分の意志ではどうにもならない抵抗感をなくすために、バージョン管理しておくという儀式が必要なのでした。