＞
結城浩の日記 ＞
2002年10月
|
＞
結城浩の日記 ＞
2002年10月
| 検索 |
| プロフィール | 日記一覧 | 日記ダイジェスト | Twitter | RSS |
|
オンラインコミュニティの運営に関してのメモ。
そして、参加者がいだく「わくわく感」が、 オンラインコミュニティを生きたものにする。
今日は、パターンに関する会合に珍しく出席しました。 お相手してくださった皆様に感謝します。 結城が人前に登場するのは、今年はこれで終わりでしょう。
大きな個人的お仕事が一段落。ほっと一息。 守ってくださる神さまに感謝。 関係者の方々に神さまの祝福がありますように。
[REF] 原稿送付。感謝、感謝。 今回のテーマは「例外」のお話。
[DP/2] ずいぶん遅くなったけれど、 『Java言語で学ぶデザインパターン入門 マルチスレッド編』 執筆の際にアドバイスをいただいたDoug Lea先生に 感謝のメールを送った。
[DIG] 日記ダイジェスト、2002年5月分を更新。
[CR] 昨夜、あれこれ作戦会議と情報交換。 つくづく、メールとWebは便利だと思う。 これで仕事の効率は何百倍にもなっているんじゃないだろうか。 もっとも、仕事の本質的な部分にかかる時間は削減できないんですけれどね。
朝、お祈りして仕事開始。
[REF] 今日も今日とてリファクタリングの連載記事。 サンプルプログラムの解説文を書き、解説の図を描く。 あとは関連する話題を書けばおしまい。 でも、プログラミングしている最中に気づいたポイントについてはすでにメモしてあるから、 それほど時間はかからないだろう。 ただ、ミスを防ぐためにちょっと時間を置く必要はあるかな。
やっぱり、神さまに祈ってから仕事をするとぜんぜん違いますね。
今日はとってもいい天気でした。 礼拝の前後、気持ちのいい日差しを浴びてのんびりしました。
昨日の日記の問題に対して、 たくさんの方から「解答」をいただきました。 反応ありがとうございます。 こういうクイズを出すと、 いろんな方からメールがもらえて何だかハッピーになりますね。
そうだそうだ、昨日の問題の解答を書くのを忘れていた。 以下に書いておきます。
解答1 (多数の方の解答)
2つのグループに分けたとき、どちらか片方は7を含む。 1から10の中で、7の倍数になる数は7しかない。 その結果、2つのグループに分けたとき、 7を含む方のグループの積は7の倍数になるが、 他方のグループは7の倍数になれない。 よって、2つのグループのそれぞれの積が等しくなることはない。
解答2 (むらかみたかしさんの解答から要約抜粋)
1から10までの積は3628800である。 2つのグループのそれぞれの積が等しくなるなら、 その値は3628800の平方根になるはず。ところが3628800の平方根は整数にならない。 よって、2つのグループのそれぞれの積が等しくなることはない。
解答1は多数の方からありました。私が用意した解答も解答1でした。 解答2はむらかみたかしさんお一人でした。 解答1はエレガントで素敵ですが、解答2もシンプルですねえ。
長男「ねえお父さん、何か問題出して」
私「じゃあ、1から10までの数を思い浮かべて」
長男「うん」
私「1から10までの数は10個あるね。これを2つのグループに分ける。AとBとしよう」
長男「ふんふん」
私「2つのグループといっても、同じ個数で分けるわけじゃない。{ 1 } と { 2から10 } みたいに
1個と9個にわけてもいい」
長男「ふんふん」
私「さて、Aのグループの数を全部掛け算する。Bのグループの数も全部掛け算する」
長男「ふんふん」
私「このとき、Aのグループの掛け算の答えと、Bのグループの掛け算の答えが等しくなることはあるか？
これが問題」
長男「じゃあ、やってみるね。{ 1から5 } と { 6から10 } だとすると…
…1×2×3×4×5と、6×7×8×9×10だね」
私「それだと、すぐ等しくならないってわかるよ」
長男「どうして？ あ、そうか。6×7×8×9×10が大きくなっちゃうのか。
じゃあ、{ 1,3,5,7,9 }と{ 2,4,6,8,10 }だとすると…（しばらく考える）」
私「それもまずそうだね。奇数と偶数だから」
長男「じゃあ、10と9を取り替えて { 1,3,5,7,10 }と{ 2,4,6,8,9 }…
…って、全部の組み合わせを試すのは大変だあ」
私「そうだね。全部で、2の10乗通り…じゃなくてその半分、512通り試す必要がある」
長男「きっと、等しくなることはないんだよ」
私「だから、それを証明しなくっちゃ」
※この問題は森博嗣の小説で知りました。有名な問題らしいです。
※みなさんも解いてみてください。
neoさんが、掲示板で、 龍に成らないことで詰められる詰め将棋のページを教えてくださいました。 ありがとうございます。
長男「ねえお父さん、何か問題出して」
私「普通の将棋は9×9だよね。横が9、縦が9」
長男「うん」
私「じゃあ、横が1、縦が3の将棋を考えよう。駒は何を置こうか」
長男「うーん…王？」
私「うん。そうしよう。一騎打ちだ。どっちが勝つ？」
長男「ええと。先手が負けるね」
私「そうだね。先手が負ける。先手必敗だ…将棋はパスができないから。じゃあ1×4なら？」
長男「今度は後手が負けるね」
* * *
私「振り駒をするとしよう。歩を5枚振る。出方は何通りある？」
長男「5通り」
私「本当かな？」
長男「5通り…だよねえ」
私「じゃあ数えてごらん。数が少ないときは実験で確かめられる」
長男「全部「歩」。一枚「と金」。二枚「と金」。三枚「と金」。四枚「と金」。全部「と金」」
私「全部で6通りだ」
長男「ほんとだ」
私「宇宙人がやってきて、100万枚の歩で振り駒をしたとする。出方は何通りある？」
長男「100万1通り？」
私「その通り。じゃあねえ。エックス枚の歩で振り駒をしたとする。出方は何通りある？」
長男「エックス・プラス1通り？」
私「その通り。なかなか賢いねえ」
長男「ふふん」
私「じゃあ、こんどは幽霊がやってきて、0枚の歩で振り駒をしたとする。出方は何通りある？」
長男「1通り？」
私「正解だ。「歩」が0枚で「と金」が0枚の一通り」
長男「でも、（振り駒って、もともと先手と後手を決めるものだから）そのときは、どっちが先手になるの？」
私「0は偶数だから、偶数枚の歩で振り駒をしていることになる。両方0で同数だから先手・後手は決められないね」
長男「なるほど」
* * *
長男「ねえ、さっきの振り駒の話だけど、二分の一枚で振り駒をしたらどうなるの？」
私「お父さんは「マイナス一枚で振り駒をする」というのを考えていたんだ。え、何？二分の一枚？」
長男「歩を半分にパキッて割るのかな」
私「うーん。二分の一枚ねえ…。一回振った結果を半分にするのかなあ…うーん」
[REF] 今日もリファクタリングの続き。 プログラムはほぼ完成。
[PI] C MAGAZINEのデザパタ連載の続き。 プログラムはほぼ完成。
親切な方が、YukiWikiに「龍に成ってしまうと負けてしまう場合がある」 という話を書いてくださいました。 「打ち歩詰めを回避するため」ということです。 なるほど。なるほど。 今度長男に話しておきます。ありがとうございました。
[REF] JAVA Developerの連載記事『結城浩のリファクタリング・レッスン』を書いている。 今回の（雑誌としては次回の）リファクタリングはReplace Error Code with Exceptionである。 まずはサンプルプログラムを淡々と。
リファクタリングというのは、プログラマの柔軟体操という感じがしますね。 お部屋の片付けのような、本棚の整理のような、そんな趣もあります。
長男「ねえ、お父さん。この間、コンピュータで見せてくれた将棋プログラムなんだけど」
私「うん。ダウンロードしたフリーのソフトだね」
長男「あれって、駒が相手の陣地に入ったとき『成りますか？』って聞いてくるでしょう？」
私「そうだったね。成るかどうかは競技者が選べるから」
長男「でもね、飛車が龍になるときって、成っても動ける範囲は狭くならないから、
必ず成るようにしてもいいんじゃないか、って思うんだ」
私「ふうむ…。確かにそうだね。じゃあ、あなたが将棋プログラムを書くときには、
そういう風にプログラミングするといいね」
長男「ふうん…」
家内「でも、ああいうプログラムって作るのは難しいんじゃないの？」
私「いや、数手先を読むくらいのプログラムなら、
それほどは難しくないと思うよ。
プログラミングを勉強して二年もしたら書けるんじゃないかな。
一年でも書けるかもしれない」
長男「ええええ！二年もかかるのお？」
* * *
私「プログラミングを学ぶのはピアノよりも簡単だと思うよ」
長男「そうかなあ…」
私「だってピアノはリアルタイムに演奏しなければならないけれど、
プログラムは何度も見直して直すことができるし」
家内「でも、ピアノはちょっとくらい間違ってもいいけれど、
プログラムはちょっとでも間違うと全体が駄目になっちゃうでしょ」
私「ピアノだってちょっと間違ったら曲全体が駄目になるじゃない」
* * *
長男「お父さん。将棋のプログラムを書く人って、将棋のことを知らなくちゃならないね」
私「そうだね。将棋のことと、プログラムのことを両方知らなくちゃならない。
銀行のプログラムを書く人は、銀行のお仕事のことを知らなくちゃならない。
プログラムを書くっていうのは、コンピュータに何かを教えるようなものだね。
あなたがアメリカの人に将棋を教えるとしたら、将棋と英語の両方を知らなくちゃいけない。
それと同じように、コンピュータに将棋を教えるためには、
将棋とプログラムの両方を知らなければね」
[PI] C MAGAZINEの新連載の初回原稿のゲラが送られてきたので、校正作業。
[CR] 今日は真ん中あたりの章をじっくりと読みながら、章立てを再構成。 ちょっと形になったかな。 ときどき、こんなことして何になるのかなあ、という思いが浮かぶが、 まずは、どっぷりと、仕事。
[CR] これまでに137286バイト書いた。 目次から全体を読み直して章立てを調整する。 分量が多くなりそうだ。うう。 まあ、でも、気にせずとっとと書き進めることにしようか。 おっと、今日から月末にかけては連載執筆なのであった。 てきぱき仕事することにしよう。
いつも、祈りつつだ。
礼拝から帰ってきてお昼寝。 起きてから書き物など。
[CR] 夜、とある方に非常にずうずうしいお願いごとのメールを出す。 どきどきしながら返事を待っていたところ、 素晴らしく太っ腹で好意的なお返事をいただく。 ありがとうございます。
今日は、ズーラシアに行きました。 曇っていて、いまにも雨が降りそうという天気だったせいか、 比較的すいていて、のんびり動物を見ることができました。 ガラスごしに間近にオランウータンやスマトラトラを見ました。 休憩所でとってもクリーミィなアイスクリームを食べました。
夜はビデオ屋さんでモンスターズ・インクを借りて観ました。
昨日のマクロとスクリプトにバグがあったので修正しました。
秀丸エディタのマクロからPerlを起動して、 擬似アウトライン機能を実現する方法について。
まず、秀丸エディタのマクロ。 ファイルを置くディレクトリ名は適当に調整すること。
// outline_grep.mac $PerlScriptFileName = "c:\\your\\own\\directory\\name\\outline_grep.pl"; $OutlineFileName = "c:\\your\\own\\temporary\\directory\\name\\outline.txt"; runsync "perl " + $PerlScriptFileName + " " + filename + " " + $OutlineFileName; readonlyloadfile $OutlineFileName;
それから、Perlのスクリプト。
# outline_grep.pl
#
# Usage: perl outline_grep.pl inputfile outputfile
# inputfileの「アウトライン」をタグジャンプできる形式としてoutputfileに出力。
use strict;
my $infile = $ARGV[0];
my $outfile = $ARGV[1];
my %indent = (
'『' => 0,
'■' => 0,
'●' => 1,
'◆' => 2,
'※' => 3,
);
my $pattern = "^(@{[ join('|', keys %indent) ]})";
open(INFILE, $infile) or die;
my @infile = <INFILE>;
close INFILE;
open(OUTFILE, "> $outfile") or die;
my $linenumber = 0;
foreach (@infile) {
my $line = $_;
$linenumber++;
if ($line =~ /$pattern/) {
my $num = sprintf("%4d", $linenumber);
print OUTFILE "$infile ($num):", ' ' x ($indent{$1} * 4), $line;
}
}
close OUTFILE;
サンプル入力ファイル。秀丸エディタでこれを開く。
『ファイルのタイトル』 ■大見出し1 説明文説明文説明文説明文説明文説明文 説明文説明文説明文説明文説明文説明文 ●中見出し1 説明文説明文説明文説明文説明文説明文 説明文説明文説明文説明文説明文説明文 ●中見出し2 説明文説明文説明文説明文説明文説明文 説明文説明文説明文説明文説明文説明文 ※メモ ■大見出し2 説明文説明文説明文説明文説明文説明文 説明文説明文説明文説明文説明文説明文 ●中見出し1 説明文説明文説明文説明文説明文説明文 説明文説明文説明文説明文説明文説明文 ◆小見出し 説明文説明文説明文説明文説明文説明文 説明文説明文説明文説明文説明文説明文 ●中見出し2 説明文説明文説明文説明文説明文説明文 説明文説明文説明文説明文説明文説明文
そして、マクロの実行結果。 タグジャンプできるようになっている。
c:\work\work\file.txt ( 1):『ファイルのタイトル』 c:\work\work\file.txt ( 3):■大見出し1 c:\work\work\file.txt ( 8): ●中見出し1 c:\work\work\file.txt ( 13): ●中見出し2 c:\work\work\file.txt ( 17): ※メモ c:\work\work\file.txt ( 19):■大見出し2 c:\work\work\file.txt ( 24): ●中見出し1 c:\work\work\file.txt ( 29): ◆小見出し c:\work\work\file.txt ( 34): ●中見出し2
秀丸エディタのマクロについては、 秀丸エディタのヘルプを参照のこと。
[CR] 今日は気分を変えて、イントロダクションを書く。 以前書いた部分は図と不整合を起こしているし、 もっと適切な例を思いついたので全部書き直すことにする。 何だか粘土をこねているみたい。ぺったん、ぺったん。
[DP/ML] 昨日は、デザインパターン・メーリングリストが急にC#の話題で盛り上がった。 デザインパターン・メーリングリストはもう3100人以上になっているのですね。 感謝なことです。
[REF] 私はJAVA Developerで『結城浩のリファクタリング・レッスン』という連載記事を書いている。 次回掲載の題材はReplace Type Code with State/Strategyになる。 先日、編集者から著者校正用のPDFが届いたので、校正の内容をメールで返事する。
お世辞を言うわけではないけれど、 JAVA Developer誌でも、C MAGAZINE誌でも、 以前連載していたUNIX USER誌でも、 丁寧な編集をしてくださるので、 著者としてとてもうれしい。
連載記事に関して少し書いてみよう。
連載記事の企画は、編集者から出てくる場合もあるし、自分から出す場合もある。 メールのやりとりや打ち合わせを通して企画を調整する。 題材、内容、タイトル、期間、ページ数、原稿料、〆切なども相談する。
月刊誌の場合、毎月の〆切があるので、遅れないように執筆計画を立てる。 調べたり、自分でプログラムを作ったり、図を描いたり、表を作ったりする。 もちろん解説の文章も書く。 いろんな記事を何年も書いてきているから、 何日・何時間あればどれだけの内容・分量の原稿を書くことができるのかは、 おおよそわかっている。 しかし、ときおり（しばしば）目算を誤って、編集者にご迷惑をかけそうになる。 その際には、できるだけ早めに、編集者へ進捗状況を伝えて、スケジュール調整をする（ように心がけている、つもりである、はず）。 正直な進捗を伝えることはとても大事だ、と思っている。
原稿を送ると、しばらく日数が過ぎてから校正がやってくる。 紙でやってくる場合もあるし、PDFでやってくる場合もある。 技術的な内容をチェックし、表現に不適切なところがなかったかを確認する。 日数が過ぎているから、だいぶ冷静に読むことができる。 編集者が反映しやすいように心がけて、修正箇所と修正内容をメールする。
編集者さんと連載を通じて長い付き合いになってくると、 互いに「相手はどのくらいの品質の仕事をどこまでやってくれるか」という 間合いがわかってくるので、 びっくりするようなトラブルはほとんどなくなる。
[CR] 今日は別の章をはじめから丁寧に書き進める。 説明文を一歩一歩進めていくと、どんどん長くなる。 どんどん長く長くなっていく。 うう。 1つの節を書き進めていったら、 それが章の長さに近づいていくというのは、 どう考えても要領が悪い。やれやれ。
説明文にあわせて図を描く。 ウソや不整合があるのは困るが、ウソを恐れるあまり話がごちゃごちゃするのも困る。 すっきりと説明できないのは、理解が足りないから。シンプルな話だ。 正しいから美しいとは限らない。美しいから正しいとも限らない。 正しい内容を美しく表現するのは、とても難しい。
昨日の夜はちょっと「つかんだ」感じがしたけれど、 今日はいま1つ。 もっと深いところに飛び込む必要があるみたい。
でも、いつも、神さまへの祈りを忘れてはいけない。 まわりの人への感謝を忘れてはいけない。
[PLPW] 二人にメールを送って、一人からOKの返事がきた。 もう一人からOKの返事が来ればおもしろいイベントが始まるのだが。さてさて。
[CR] 午後にも説明文を読み返したり、書き加えたり、図を描いたり、…とぐりぐりと仕事。 参考書をぱらぱらめくっていると、ちょっとアイディアがひらめいて一人で感動。 あわててエディタを開いてメモメモ。
とても天気がよい。
今日は、次男の咳はずいぶんよいようだ。感謝。 少し離れたところにある大きな公園に出かける。 次男はすべり台ですべったり、アスレチックのような遊具で遊んだり。 途中、転んだ拍子に木の椅子に思いっきり頭をぶっつけて大泣き。こぶができた。 くたびれたけれど、何だか充実。
夜眠るとき、次男が「イエスさまのお話を読んで」というので聖書物語を読む。 それからスキャリーさんの英語の単語の本を読む。 いつも帽子を追いかけているフランブルさんが楽しい。
英語と言えば、 最近わが家ではNHKの『英語であそぼ ゆかいなファミリーラップトーン！』を楽しく観ている。 うちではテレビはほとんどつけないのだが、 この『英語であそぼ』と『いないいないばぁ』と『おかあさんといっしょ』だけは観ている。 『英語であそぼ』を見ているせいか、次男の発音はnativeみたい(語彙はすごく限られているけれど)。 家内はVOCARACE(ボキャレース)がとても好き。 VOCARACEといえば、同じアルファベットのドライバーはみんな同じ乗り物に乗っている。 特に「S」は複数形のためか、必ず複数人のドライバーが一台に乗り込んでいるようだ。 たとえばSANTAS, SATURNS, SAUSAGESなど。
[CR] 夜。例によって図を描く。 2〜3時間かけて6枚の図を描いた。 できるだけ、意味がよく伝わるように心がけて図を描いている（つもり）。 まず図を描いてみて、その図をじいいいいいいっと見る。 それから読み流すようにして図をちらちらと見る。 次に図の中の構成要素を一個一個確認しながら見る。 そういう作業を何度も何度も繰り返して図を直していく。 そうすると「ああ、これはこういう意味だったのか」 「あの点よりはこちらの点を強調すべき」 「あの図とこの図を対比させるような描き方にすべき」 などといったことに気がついてくる。 大事なのは、 まず描いてみること。 そして時間をかけて見なおし、手間を惜しまず描きなおすこと。
図を描くためには制約がいろいろかかってくる。 例えば紙は二次元だとか、うまく描かないと線が交差するとか。 その制約の中で、「きれいな」図を描こうとしていると、 隠れていた構造がひょっこり顔を出してくることがある （隠れていた構造、といっても私が単に気がつかなかっただけなんですけれど…）。 それは、驚きと喜びが混じりあった、とても楽しい体験だ。 いつも散歩している砂浜で、美しい貝殻を見つけたときのように。
次男は風邪で、咳がひどい。 次男に「早く治るといいねえ」と言うと、 次男は私をたしなめるように「イエスしゃまって、いうの。なおんの」と言う。 なるほど、確かに。と思い、次男の風邪が早く治るようにと祈る。
[CR] 夜。ちまちまと図を描く。 図を描いているうちに、 いままでさらっと流していた部分の意味がはっきりと分かってすごく感動した瞬間が訪れた。 「な、なるほど！」 感動が通り過ぎてからよく考えてみると、 ふだんからきちんと資料を読んでいれば当然理解していてしかるべき内容だったということに気がついて、 しばし反省。
[CR] 全体像がだいぶ見えてきた（ような気がする）ので、 そろそろ1つの章をきっちり書き上げてみようと思う。
で、ていねいに書いていく。 ざっくり書いていた文章をひとつひとつ読み、きちんと直す。 例も、図も、人に見せられるレベルまで仕上げていく。 当然ながら、書いているうちに自分の理解していないことが出てきたり、 新たな疑問がわいてきたりする。 こういうときの疑問はとても重要である。 それは読者（特に注意深い読者）が感じる疑問に近いからだ。 すぐに解決できなくてもいいから（たいていは解決できない）、 疑問点はちゃんとメモしておく。
書いているうちに詳しくなりすぎて、節が長くなってしまうこともある。 節を他の場所に移動したほうがいいかなあ、と感じた場合でも、 節の内容はきっちりと文章にしておくほうがよい。
さて、いつものことだけれど、 ここまでのような作業をしっかりやっていくと、 章がとても長くなってしまう。 大概は、当初予定している倍の長さになってしまう。
学生のころ、作文の授業では必ず先生が「長く書くのは楽だが、短く書くのは難しい」と教えたものだ。 ふんふん、と聞きながら心の中では「でも実際には指定された長さに届くまでが大変なんだよな」と思っていた。 しかし、いまは違う。実感として「長く書くのは楽だが、短く書くのは難しい」と言える。 長く書くのは楽だ。意味が通る文章で、という条件をつけたとしても、いくらでも長く書ける （いくらでも、というのはいいすぎかもしれないな）。 でも、短く書くのは難しい。短く削っていくのは難しい。短くまとめるのは難しい。
なぜか。
その文章全体で表したいことの「本質」をしぼりこむことが難しいからだ。
実家の母親は短歌をやっている。 「短歌はみそひともじ。31文字しかないから無駄なことはいえない」 ということを以前教えてもらった。 短歌と説明文では方法論は違うけれど、 短くするのは難しい、という点では同じだ。
いま、ふと、気がついた。 私たちの毎日の生活も、もしかしたら同じだろうか。 朝起きて、夜眠るまで、私たちに与えられている時間は１日２４時間。 ２４時間しかないから、無駄なことはできないのかもしれない。
私の人生全体で表したいことの「本質」って何だろう。
[CR] 今日は本の町、神保町に出かけました。 書泉グランデで参考書を何冊か買いました。
[DP][DP/2] 書泉グランデには 『Java言語で学ぶデザインパターン入門』と 『Java言語で学ぶデザインパターン入門 マルチスレッド編』が平積みされていたので、 感謝しつつ、 そっと手を置いて祈ってきました。 「神さま、御名をほめたたえます。この本を必要としている読者にお届けください」
[CR] その後、夕食を食べ、家に帰ってから調べ物をしていると、 参考書のとんでもない大きな間違いを見つける （いや、間違いじゃないのかもしれないけれど）。 確認のために著者にメールをする(一応errataはチェックした)。
[PLPW] ちょっと別件でおもしろそうな題材を見つけたので、 一応[PLPW]とIDだけはふっておこう。 関連する人にメール。 さて、どうなりますでしょうか。 わくわく。
[Letter] 久しぶりに[Letter]を送信。
[CR] バスを待ちながら「はじめに」の書き出しを考えてみる。
マクドナルドに着いた。 手が動くまま「はじめに」を書いてみる。 うーん。まだまだだなあ。
手が動くままイントロの章を書いてみる。 イントロはとても難しい。 いきなり深い解説を書きそうになって少しブレーキをかける。 うーん。
目次を見ながら、本の全体像を表現する図をスケッチしてみる。 なかなかうまく描けないものだなあ、と思う。 図を描いていると、自分の理解が不十分な部分が見えてくる。 うまく収まりが悪い概念が見えてくる。 参考書を調べてみて、 収まりが悪いのは私の理解がまずかったからだ、と思う。 理解がまずかった部分について再考してみる。 修正する。
じっくりと、いろんなことを考えるのはとても楽しい。 リアルワールドとも違う。ネットとも違う。 まったく別の世界に旅行に出かけるような気持ちになる。 カメラも持った。パスポートも持った。ガイドブックも忘れずに。 エアチケットはポケットの中。さあ出かけよう。 見たこともない（けれどどこかで見たような）景色が広がる。
「コーヒーのお代わりいかがですか」と、 マクドナルドのお姉さんが声をかけてきて、 私はものすごくびっくりして急激にリアルワールドへ戻ってくる。
[PI] C MAGAZINEのパターン連載、 第一回目の内容やリンクなどを簡単に紹介。
[CR] 夢の中でも図を描いていた。やれやれ。 昼間は思いつくまま文章をスケッチ。 夜は図を数枚描く。慣れてきたせいか、失敗が少なくなってきた。 よろしい。なかなか、よろしい。
[SHOP] アマゾンから「結城さんちの本屋さん」へ三か月分のギフト券が届いたので、 例によって同額をユニセフに送金。 みなさんお買い物ありがとうございます。
[DP] 『Java言語で学ぶデザインパターン入門』が増刷になるとのこと。 応援してくださる読者のみなさんに感謝し、 イエスさまに栄光をお返しいたします。
密度の高い情報を日記でいつも提供してくださる森山和道さんから、 「図は何で描いてますか？」との質問メールが。 Visioで描いてます、と返事メールを出す。
今日は、家族みんなで砧公園へ出かけ、 アスレチックな遊具で遊びました。
[CR] 夜。 また図を描いています。 頭の中では「自明」のように思われていたことでも、 実際に図にしてみると難しいことがわかります。 いや、もちろん、理屈が通っている図を描くことはすぐできるんですよ。 でも、その理屈が人にスムーズに伝わる図を書くことはとても難しいのです。 どうやったらうまく伝わるんだろう、 どうやったら分かってもらえるんだろう、 ということを時間をかけて真剣に考える。 考えては描き、考えては描く。 それから、読者の気持ちになって図を読んでみる。 じっくりと読んだり、全体を眺めてみたり。 そして、また考えては描き、考えては描き。 そういうことをやっていると、説明の文章や適切な例などをふと思いついたりするので、 すかさずエディタでメモを取っておく。 そして、また考えては描き、考えては描き…。
[CR] というわけで、夜はひたすら図を描く練習なのだ。 図も文章と似ていて、ていねいに描いているうちに、 だんだん自然な流れが見つかってくる。 大事なのは、最初に描いた図は全部捨ててもかまわない、 という気持ちで、でもていねいに描くこと。 何回もゼロから描いているうちに、 いろんな発見がある。 図が何かを物語ってくれるのかしらん。 今晩は図を8枚描いて4枚捨てました。
でも、図を描いているうちに、 ちょっぴり「何かをつかんだ」みたいな気分。
…眠い…。
うれしいメールが何通かやってきた。 うれしい、うれしい。 感謝、感謝。
[CR] 今日は「はじめに」の部分の章立てのところを書いた。 各章の内容を一言二言で説明する。 文章は、短く書くのは難しいものだ。 ていねいに、ていねいにね。 書いているうちに、より自然な話の流れを見つけ出すことが多いので、 その流れにしたがって、章立てを微調整する。 章のタイトルも大事だ。
それから最初の章を書き進めてみる。 すでにブレーンストーミングで書き出した題材のメモが最初の章のファイルにまとめてあるので、 それを見ながら、ストーリーを組み立てていく。 扱っている題材を読者がまだあまり知らないことをよく思い出し、 読者の気持ちになって、自然な流れになるように書き進める。 読者が道を見失わないように道しるべとなる小見出しをつけていく。 図が必要そうな部分には「ここに図」などとメモを書いておく。 まだ細かな文章の誤りを直したりはしない。 いわばコンテの段階なので、文章の「てにをは」に気をつかわず、 とにかく一気に書いてしまう。 とはいっても、文章の誤りは気になるので、ついつい直してしまうけれど。
全体を見渡した構成をするのは頭がすっきりしている朝や午前中がよい。 頭のキャパシティに余裕がないと、全体を見渡すことができないからだ。 それから、図を練るのは夕方から夜のほうがよい、と経験的に感じている。 頭のキャパシティに余裕があるときに図を練ると、複雑すぎる図になってしまうからだ。 図は何かを説明するものだ。説明したいポイントが自分でわかっていないと、 適切な図を描くことはできない（当然のことだ）。
私は、読みやすくてわかりやすい説明文が大好きだ。 そういう文章を読むのも好きだし、書くのも好き。 読みやすい文章を見つけたときには、 どうしてその文章が読みやすいのかをじっくり研究する。 でも、なかなかその秘密を伝えるのは難しい。 さまざまなものが微妙なバランスの上に成り立っている。 細部もよくできていて、全体もよくできているときに、 読みやすくわかりやすい文章になるからだ。 それはほいほいと「盗む」ことはできない。 毎日、毎日、愚直に、素直に、自分の頭で考えて手を動かして、 実際に書いてみて、読み直してみて、また書き直してみて、また読み直してみて、 全部捨てて最初から書き直してみて、 …というのを繰り返していくしかないのだろう、と思う。
そういえば、以前、村上春樹の紀行文を研究したことがある。 中華レストランのバーミヤンで鶏のピリ辛炒めを食べてビールを飲みながら、 ボールペンで文庫本に書き込みをしていったのを「研究」などと 呼んだら怒られるけれど。 ともあれ、単語の使い方や、文章同士の関係を調べてみて、 とてもよくできているのに驚いたのを記憶している。
本屋さんで、 読みやすくてわかりやすい本に出会うと、 とてもハッピーな気持ちになる。 読みやすくてわかりやすくて、 さらによい内容だったら最高ですね。
さあ、神さまに祈りつつ、仕事仕事。
[CR] 今日も今日とて本を書く。 本を書いていると 「そんな本を書いても何の役にも立たない」というささやき声が聞こえてくる。 「あなたにはちゃんとした本なんか書けない」や 「似たような本はすでにたくさん出ているから何の意味もない」や 「時間の無駄無駄」とかね。 特に、うーん、ここどうしたほうがいいかなあ、 と判断に迷うときに聞こえてきますね。 ああ、もう、うざいったら。 キック、キーック。
集中して仕事をしよう。 じっくり、ていねいに仕事に立ち向かおう。 勇気をもって、神さまに祈りつつ進もう。 感謝しつつ、喜びつつ。
…と書いていたら、 ちょうどはちこさんの日記でも「喜び」というテーマが登場していた。 感謝です。
God is Good!
God is Gooooood!
God is Goo+d! (Perlの正規表現で、o+ はoの一回以上の繰り返し)
[CR] 新しい本の章立てを考えている。 目次を作って編集長さんに見てもらったり、 筆慣らしに一章書いてみたり、 前書きを書いたり、参考書を読んでメモを取ったり。 楽しい。 でもまだ、ちゃんと「つかんで」いないような気がする。
適当な章をピックアップして、 思いつくまま書き進める。 まずはどんどん書いてみて、そのあとで順序を入れ替えたり、見出しをつけてみたりする。 そうこうしているうちに、章内の構成がだんだん整ってくる。 すでに書きすぎているので、あちこち削除して刈り込み。 1つの章をだいたい20KBから30KBくらい収めるのが私の目安。 雑誌の連載原稿一回分とだいたい同じ。
章内の構成を考えているうちに、 どういうところに「遊び」や「お楽しみ」を入れて、 どういうところで「シメる」かの具合もだんだんわかってくる。 いったん自分の知識を忘れて、 何も知らない読者の気持ちになってみたりもする。 女性が外出する前に何度も何度も鏡の前で（つまり他の人の目になって）服装をチェックするように、 文章構成の具合を読者の目になってチェックする。
自分の知っていることを、 ていねいに読者に伝えるように努力する。 言葉を使ってきちんと説明しようとすると、 自分が何を理解していて何を理解していないかがはっきりしてくる。 （逆説的だけれど）言葉で嘘はつけない。
じっくり調べ物をしていると、 参考書の間違いをときどき見つける。 昨日も1つ見つけたので、 errataにないことを確認してから著者にメール。
考えては書き、書いては考える。 こういうのをいろいろとやっていると、 頭のさまざまな部位を動かしているようで、 とても楽しくなり、やめられなくなる。
でも、まだ[CR]は「つかんで」いないなあ…。
もう10月かあ…。
The Web KANZAKIさんの新着情報はRSS(RDF Site Summary)でも提供されているが、 Internet Explorerで見るとXMLのツリー構造ではなく、 ちゃんと人間が見やすいようにレンダリングされる。 ソースを探求してみると、XSLTのスタイルシートを使っている模様。 さっそく拙サイトwww.textfile.orgのRSSでまねっこしてみることにする。
ちなみに、 https://www.hyuki.com/tf/tf.xml はPerlで、XML::RSSモジュールを使って書いています。 https://www.hyuki.com/tf/tfxsl.xml は秀丸で手書きです。
あなたのご意見・感想をお送りください。 あなたの一言が大きなはげみとなりますので、どんなことでもどうぞ。