＞
結城浩の日記 ＞
2004年8月
|
＞
結城浩の日記 ＞
2004年8月
| 検索 |
| プロフィール | 日記一覧 | 日記ダイジェスト | Twitter | RSS |
|
先日 「FAX複合機がうまく使えない」という話題を日記に書きました。 いろんな方からアドバイスをいただいたのですが（感謝）直接的な解決には至っていませんでした。 先日、奥さんから「サポートに電話したら？」と言われて電話をしました。 あまり期待していなかったのだけれど、たいへん対応がよく、テキパキとしたやりとりが進み、 無事に解決しました。
一番問題だったのは、電話回線とFAX回線が一本のため「FAXを試しに送る」という実験ができなかったこと。 でもサポートの人と携帯で連絡を取りながら何度も送ってもらったのが功を奏しました。
MP740の設定
時間の設定
電話が鳴り始めてから24秒後に留守電側が電話を取ってメッセージを流し始める。 そのときにMP740側は「これはFAXだな」と判断してFAXを受信してくれることになる。 MP740側が取るよりも先に留守電が取ることが重要。
ところで一方では、 FAXの送信側のタイマーが切れる（あきらめる）時間というものもあるらしい。 約30秒だったかな。 MP740の呼び出し時間はこれよりも短くしなければならない。 さもないと、せっかく留守電が電話を取ってくれても、送信側が先に切れてしまうから。
上記の設定で、うまくいくはず。 ところが、どうもうまくいかない。 ここでサポートの人は、社内の実機で同じ設定での動作を確認してくれた。
サポートの人は、電話口で「こちらでは同じ設定でうまくいっているんですが…。 それでは工場出荷時の設定に一度戻してから再度やってみましょう」という案を出す。
サポートの人の指示に従って初期設定を行い、上記の設定で再度チャレンジしてみたところ、 無事にFAXを受信できるようになった。もちろん留守電もOKである。
キヤノンのサポートセンターの方、ありがとうございました。
奥さんがローカルに書く日記(ネットで他の人に公開するわけではない日記)が欲しいというので、 それはやっぱりtDiaryだよ、と勧める。 何でもよいから使えるようにせよ、との指示が下ってインストール。
お題： Apache, Ruby, tDiaryのいずれもインストールされていないWindowsマシンでtDiaryを動かす。 ただし、書き込むのも見るのもそのマシンからだけでよい。
手順は次の通り。
以下、順番に解説する。
Windows版のApacheをC:\Program Files\Apacheにインストールしよう。
ApacheのDownloadのページからWin32 Binary (MSI Installer)をダウンロードする。 ファイル名は、 apache_2.0.50-win32-x86-no_ssl.msi である。 ファイルをダブルクリックしてインストール。
設定ファイルを書き換えよう。
C:\Program Files\Apache\Apache2\conf\httpd.conf に以下のような項目を追加する（ディレクトリ名などは仮名）。
Alias /diary/ "C:/Documents and Settings/okusan/diary/"
<Directory "C:/Documents and Settings/okusan/diary/">
AllowOverride All
Order deny,allow
Deny from all
Allow from localhost
</Directory>
AllowOverride Allは、.htaccessの設定を有効にするため。 Order deny,allow, Deny from all, Allow from localhostは、 自分自身からしか閲覧できないようにするためです。
Ruby-mswin32 (ja)からruby-1.8.1-i386-mswin32.zip (最新Release版)をダウンロード。 C:\rubyに展開する。 一応C:\ruby\binにPATHを通したが、特に設定は不要なんじゃないかなあ。
tDiaryのダウンロードのページからtdiary-full-2.0.0.tar.gzをダウンロード。gunzip, tarで解凍。READMEを読む。
tdiary-2.0.0以下のファイルをごっそりとC:\Documents and Settings\okusan\diaryへコピー。
index.rbとupdate.rbの一行目を次のように修正。
#!/ruby/bin/ruby.exe
tdiary.confの次の行を変更。
@data_path = '/Documents and Settings/okusan/diary/files'
C:\Documents and Settings\okusan\diary\filesというディレクトリを作る。
C:\Documents and Settings\okusan\diary\.htaccessに以下の内容を書く。 「ローカルでしか更新しない」という前提なので、 tDiaryの配布ファイルに含まれていたdot.htaccessは利用しなかった（dot.htaccessのほうにはupdate.rbにBasic認証をかけている）。
Options ExecCGI FollowSymLinks AddType application/x-httpd-cgi .rb DirectoryIndex index.rb
ブラウザからhttp://localhost/diary/にアクセス。 あとは、ブラウザ経由で必要な設定を行う。 他のマシンからアクセスできないことを確認。
以上。
プログラマのダイエット(51日目)
はてなダイアリーライター（はてダラ）を使って、 はてなダイアリーを更新するのはとても楽。 なので、こちらの日記がついおろそかになる。
www.hyuki.com/diaryでは、以下の3プロセスを経て「更新」が行われる。
これは、コンパイラを使ったプログラム開発と似ている。
一方、d.hatena.ne.jp/hyukiでは、以下の2プロセスを経て「更新」が行われる。
これは、スクリプト言語を使った開発と似ている。
この2つは、私の意識に合致している。
1.は、変換プロセスを意識している。 いったん自分の手元で別の言語に変換してからpublish/executeしている。 一方、2.は変換プロセスを意識していない。書いたら即publish/executeしている感じ。
変換プロセスの有無は「プリチェックの有無」に近いかもしれない。 書いた後、何らかのチェックがいったん行われるかどうかということだ （あくまで意識上の話です。Perlでも実行前にはチェックが行われますからね）。
makeweb.plは括弧の対応にうるさい。括弧の対応が崩れているとHTMLは作られない。 一方、hws.plやhw.plは基本的にコンテンツのチェックをしない（ちょっとはする）。 hws.plやhw.plを作っているときには意識していなかったけれど、 こうやってみると一貫性が見えてきて興味深い。
自分の意識に合致したツールを作る／使うことは心地よいものだ。
はてなダイアリーライター（はてダラ）は、ローカルなファイルをはてなダイアリーに自動送信するPerlスクリプトです。
「はてダラ」ウィークも過ぎたので、Version 1.0.0 として正式リリースしました。 今後 （致命的なバグがない限り）スクリプトの修正はしばらく行わない予定ですので、これまで「様子見」していた方もぜひどうぞ (^_^)。
はてなダイアリーライター（はてダラ）は、ローカルなファイルをはてなダイアリーに自動送信するPerlスクリプトです。
さて「はてダラ」ウィーク最終日となりました。 ハハハハさんのパッチを入れて0.9.0としました。 機能追加はこれでおしまい。後は大きなバグが出たときに修正します。 明日の朝くらいには1.0.0になっていることでしょう。
2004年10月3日に行われる、 福島テレビアナウンサーによる朗読会「アムルーズ」で、 結城が翻訳した『賢者の贈り物』が朗読されるとのことです。 関係スタッフの方からわざわざご連絡をいただきました。 ありがとうございます。
以下は予定です。
作品：オー・ヘンリー作 結城 浩訳 『賢者の贈り物』 開催日時：平成１６年１０月３日（日） 開催場所：福島県南会津郡田島町 御蔵入交流館 田島町文化ホール （約４００名収容） 出演者：福島テレビアナウンサー 入場料：無料
はてなダイアリーライター（はてダラ）は、ローカルなファイルをはてなダイアリーに自動送信するPerlスクリプトです。
今日もまったりとバージョンアップをする。 今日入れた機能（やったこと）は、
などでした。 今日も、 はてなダイアリーライターというキーワードをウォッチしながら、 id:kusigahamaさん、 id:ishinaoさん、 id:yms-zunさん、 id:rnaさん、などなどのサイトから情報をいただきました。 ありがとうございます。
はてなダイアリーライターが誕生して、明日でちょうど一週間。 結城自身が使う分にはもう十分になっていることもあり、 明日くらいでバージョンアップはいったん止めようと思っています。
なんばさんとハハハハさんをはじめとする多くの方からの情報により、 はてなダイアリーライターはどんどんバージョンアップ。
といっても機能アップをしているわけではなく、 正しいエラー処理や設定ファイルの読み込みなどの使いやすさの充実をはかっている。 それからスクリプトを整理してできるだけ読みやすくなるようにした。 Perlの関数プロトタイプをはじめて使ってみたり。
他の人からの反応があると、ツールの開発はとても楽しい。
設定ファイルを別ディレクトリに置くようにすると、 はてなグループの日記「使い分け」も楽にいくかもしれませんね。
おとといから作り始めた、はてなダイアリーライター（略称：はてダラ）は、 いしなおさんのblogmapで瞬間風速4位(24pts)になった模様。 「はてな」はユーザ数が多いので、反応が多くて楽しい。 ツールを公開するなら「はてな」に絡めると良いかも。
いま、あるといいなあと思うのは、 はてなダイアリー互換の日記CGI。 静的HTMLに変換するツールでもよい。 Perlで書かれていてフリーに使えるのがいいなあ。 はてダラのプレビューに使ってもよいし、自分の日記CGIとして使うのもよいし。
はてダラは、今朝バージョンアップして0.3.0を公開しました。 「ちょっとした更新」に対応する-tフラグや、デバッグ情報を表示する-dフラグの追加など。
ところで、 Perlの標準モジュールだけで、エコーバックなしのパスワード入力はできるでしょうか。 どなたかご存知ありませんか？（教えてクンモード）
auroraさんから情報をいただいて、 MD5でコリジョンを起こすファイルがやっと作れました。auroraさん、ありがとうございます。
以下のスクリプトを動かすと、a.dat, b.datという2つのファイルを作ります。 この2つのファイルは違うものなのに、MD5ハッシュ値が同じになります。
MD5ハッシュ値が同じになることを実際に確かめると、なんとも感慨深いものがあります。
#
# This script is based on the article
# "Collisions for Hash Functions
# MD4, MD5, HAVAL-128 and RIPEMD
# by Xiaoyun Wang, Dengguo Feng, Xuejia Lai, Hongbo Yu".
# http://eprint.iacr.org/2004/199.pdf
#
# ...and these web pages.
# http://www.rtfm.com/movabletype/archives/2004_08.html#001055
# http://slashdot.jp/comments.pl?sid=203703&cid=607766
#
# This script is written by Hiroshi Yuki. (Thanks to aurora-san!)
#
use strict;
use Digest::MD5 qw(md5_hex);
my $a = <<"EOD";
d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
2f ca b5 87 12 46 7e ab 40 04 58 3e b8 fb 7f 89
55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 71 41 5a
08 51 25 e8 f7 cd c9 9f d9 1d bd f2 80 37 3c 5b
d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6
dd 53 e2 b4 87 da 03 fd 02 39 63 06 d2 48 cd a0
e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 a8 0d 1e
c6 98 21 bc b6 a8 83 93 96 f9 65 2b 6f f7 2a 70
EOD
my $b = <<"EOD";
d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
2f ca b5 07 12 46 7e ab 40 04 58 3e b8 fb 7f 89
55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 f1 41 5a
08 51 25 e8 f7 cd c9 9f d9 1d bd 72 80 37 3c 5b
d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6
dd 53 e2 34 87 da 03 fd 02 39 63 06 d2 48 cd a0
e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 28 0d 1e
c6 98 21 bc b6 a8 83 93 96 f9 65 ab 6f f7 2a 70
EOD
print "Message A:\n", $a;
print "Message B:\n", $b;
$a =~ s/\s+//g;
$b =~ s/\s+//g;
$a = pack("H*", $a);
$b = pack("H*", $b);
print "MD5(A) = ", md5_hex($a), "\n";
print "MD5(B) = ", md5_hex($b), "\n";
open(FILE, "> a.dat") or die;
binmode(FILE);
print FILE $a;
close(FILE);
open(FILE, "> b.dat") or die;
binmode(FILE);
print FILE $b;
close(FILE);
「はてなダイアリーライター」(hw.pl)をバージョンアップ。
「はてなダイアリーライター」というツールを作ってみました。できたてほやほや。バグいろいろ。 (^_^;
21時08分: はてなダイアリーライターのバグ取りをしました。 いちおう使えるようになったはず。バージョン 0.1.0 として公開。
スラッシュドットの「SHA-0、MD5、 MD4にコリジョン発見、reduced SHA-1も」を読んで、 実際にMD5のコリジョンを起こすファイル群というのを作ろうと思ったのですが、 まだうまくいきません。 コリジョンが起きず、全部違うハッシュ値になってしまいます。 何がいけないんだろう。
#
# This script is based on the article
# "Collisions for Hash Functions
# MD4, MD5, HAVAL-128 and RIPEMD
# by Xiaoyun Wang, Dengguo Feng, Xuejia Lai, Hongbo Yu".
#
# http://eprint.iacr.org/2004/199.pdf
#
# This script is written by Hiroshi Yuki. Version 0 (does not work well).
#
use strict;
my $M_ = "02dd31d1 c4eee6c5 069a3d69 5cf9af98 87b5ca2f ab7e4612 3e580440 897ffbb8 0634ad55 02b3f409 8388e483 5a417125 e8255108 9fc9cdf7 f2bd1dd9 5b3c3780";
my $N1 = "d11d0b96 9c7b41dc f497d8e4 d555655a c79a7335 0cfdebf0 66f12930 8fb109d1 797f2775 eb5cd530 baade822 5c15cc79 ddcb74ed 6dd3c55f d80a9bb1 e3a7cc35";
my $M0 = "02dd31d1 c4eee6c5 069a3d69 5cf9af98 07b5ca2f ab7e4612 3e580440 897ffbb8 0634ad55 02b3f409 8388e483 5a41f125 e8255108 9fc9cdf7 72bd1dd9 5b3c3780";
my $H1 = "9603161f f41fc7ef 9f65ffbc a30f9dbf";
my $N2 = "313e82d8 5b8f3456 d4ac6dae c619c936 b4e253dd fd03da87 06633902 a0cd48d2 42339fe9 e87e570f 70b654ce 1e0da880 bc2198c6 9383a8b6 2b65f996 702af76f";
my $H2 = "8d5e7019 6324c015 715d6b58 61804e08";
my %message = (
x11 => $M_ . $N1,
x12 => $M0 . $N1,
x21 => $M_ . $N2,
x22 => $M0 . $N2,
);
foreach (sort keys %message) {
my $filename = "$_.dat";
print $filename, "\n";
open FILE, "> $filename" or die "$!";
binmode(FILE);
my $message = $message{$_};
$message =~ s/ //g;
print FILE pack("H*", $message);
close(FILE);
}
(12:28) 以下の情報によると、IVのエンディアンネスにも問題があるらしい。 つまり、論文の著者は、実際のMD5とはエンディアンネスの違うIVを使っている模様。
昨晩は妙にいらいらして、私の機嫌が悪かった。 なので、奥さんに「私、機嫌が悪いみたいだから、もう寝ちゃうね！」と宣言し、 子供の世話や後片付けや戸締りを全部放り出して、とっとと眠った。
眠るのはとてもよい。目が覚めたら、機嫌がよくなっていた。 頭も心もガベージコレクションがすんだあとのヒープのようにさわやかだ。 眠るときにはリファレンスカウントではなくマーク＆スイープがよい。 時間はたっぷりあるし、自己参照ループに陥っているセル群もコレクトできるからだ。
奥さんに、昨日は機嫌が悪くてごめんなさいと謝る。 昨日は、 リファレンスカウントによるガベージコレクトしかできなかったんだ、 とは言わなかったけれど。
* * *
本を書いている。
[mo]の章をまだまだ読み返している。でも、少しずつ形になってきているのでうれしい。 実例をベースにして、それをていねいに説明しようとしてみると、この章で何がポイントなのかがよくわかってくる。 一見それは順番が逆のようなのだけれど、そうではない。これが正しい順序なのではないだろうか。 実は「実例」のほうが偉いのだ。
* * *
そういえば、先日森博嗣の文庫本を読み終えたとき、 最後の解説を森山さんが書いていることに気づいた。 ロイディ、いい味だしてるよね。
この機会に10個に限定せずリストアップしてみようと思います。 以下、順不同。
本を書いている。
[mo]の章を書く。先日書いた節を読み返して書き直し。それから図を描く。 じっと読み返して気になるところを書き換える。 そしてまた読み返して気になるところを書き換える。 そしてまた…。
OSを入れた後にインストールする10のアプリケーションや、 OSを入れた後にインストールする10のアプリケーション(jishihaさん)に触発されて。 以下、順不同。
礼拝の後、お昼ごはんはなぜか家族みんなでカップヌードルになった。 ビデオ屋さんで「ファインディング・ニモ」と「猫の恩返し」を借りてきたので、 ビデオを見ながらカップヌードルを食べる。 ビデオもカップヌードルもすごく久しぶりで、子供たちは大喜び。
子供たちは大喜びだけれど、私はひたすら原稿を書くのだ。 書き書き。
プログラマのダイエット(1ヶ月＋5日目)
はちこさんとぼぼるパパさんが翻訳していた本 『境界線（バウンダリーズ） 〜〜聖書が語る人間関係の大原則〜〜』（地引網出版） がもうすぐ(9月?)出版になるとのこと。 おめでとうございます！
現在私が書いている本にも「境界線」が出てきます（ちょっと意味はちがいますけれど…）。 プログラムのバグやトラブルって、多くの場合「境界線」上で発生するんですよね。 小さい粒度ですと、配列のサイズを越えたエラー。 大きい粒度ですと、モジュール間のインタフェースのエラー(コントラクトのミスマッチ？)。 でも、いずれの場合でもエラーというものは、 もしかしたらやはり人間の間のミスコミュニケーションが原因かも。
土曜日はどんどんと仕事。連載原稿書き。
* * *
おれカネゴンさんちで紹介されていた はてなマップをwww.textfile.orgで 紹介したところ、小関さんからお手紙をいただきました。 以下、許可を得てご紹介。
はじめまして。小関と申します。いつも拝見しています。
僕の作った「はてな地図」が紹介されていたのでとても驚きました。ご紹介ありがとうございます。
「はてな地図」はGraphvizで描いているのですが、 このソフトの存在はwww.textfile.orgで知りました。 そして何かこれで面白いものは出来ないかと考えて作ってみたのが「はてな地図」です。 だから「はてな地図」がそちらで紹介されるのは僕にとって非常に感慨深いです。 Graphvizを紹介して頂けなければ、「はてな地図」は無かったと思います。 この感慨をちょっと伝えたいと思って、連絡致しました。 とにかく、ありがとうございますと言いたいです。
そして今後もwww.textfile.orgの更新を楽しみにしています。
このお手紙に、思わずにっこりしてしまいました。 もともと Graphvisは、新山さんの日記で紹介されていたものなので、 以下のような紹介リンクをたどったことになります。
いろんな人がおもしろいものを紹介するリンクが、 さらにおもしろいものを生み出すきっかけになるという例でした。
木曜日は黙々と仕事。 連載原稿書きと[mo]章書き。
例は嘘をつかない。例を頭の中で考えるだけではなく、 きちんと言葉と図にして表現してみよう。 そうすると、その例が示している事柄がはっきりとする。 で、そのはっきりした事柄は、実は最初に自分が頭で想像していた内容とは違うこともある。 きちんと表現することは大事だ。とても大事。
「例は嘘をつかない」という話を、私は以前書いているはずだ。grepする。あった。
これは Javaのマルチスレッド本を書いているときの日記だね。 Active Objectパターンを書いているときの話だ。 「自分の理解」と「例を作る」とを関連付けて書いている。
[mo]の章を書いている。考えながら、書いている。
全部の章をざっと見直して、構成を整える。 教訓を元にして例題を中心に据え、題材を絞り込む方向で整理。
[mo]の章を、じわじわと書き進める。 一節書き直してはPDFにして、じいっと眺める。読者の気持ちになって読み返す。 粘土をこねるように、その節をこねまわしす。 またPDFにして、じいっと眺める。その繰り返しをえんえんと続ける。 気の長い話だ。でも楽しい。
短いインターバルで、何度も何度も同じようなことを繰り返し、 繰り返しているうちに、少しずつ少しずつ、本当に少しずつ望む方向に変化していく。 よくなっていく感触がつかめると、どんどんおもしろくなってくる。
ん？
これって、本を書く話とストレッチの両方に通じるね（今日の発見）。
* * *
話は変わりますが、 先日書いた 「仮想キャンプ」 のシリーズのうち、 アルマさんやリベラさんたちとの「対話」に関して、 数人からフィードバックをいただきました。 共感する方が予想以上に多かったようです。
本を書いている。それから、連載原稿も書く。
[lo]の章はプリントアウトして朱を入れる作業に入る。
今日から[mo]の章に入る。といってもすでに題材は仕込んである。 いつ描いたか忘れたけれど、図版もすでに何点かできている。 先日の教訓を活かし、自分が頭で作った構成はいったん忘れ、例題をていねいに解説する。 そうすると自然に説明すべき概念や、導入すべき用語が出てくるので、 それを鳥捕りのおじさんのように捕まえていく。
鳥捕りのおじさんって知ってますか。
私は学生の頃、YMOの誰かだったか冨田勲だったかがシンセサイザーで演奏した「銀河鉄道の夜」という曲を聞いた。 宮沢賢治の『銀河鉄道の夜』を元にした曲だ。 その中に、鳥捕りのおじさんの曲があった。 私は、のんびりしていてどこか間抜けなその曲が好きで、次のような歌詞をつけた。 今でも歌える。
鳥捕りのおじさん 鳥捕って過ごす
鳥捕りのおじさん 鳥捕って過ごす
白い鳥から 白いお菓子
黒い鳥から 黒いお菓子
空から言葉がやってくる。それを捕まえる。その言葉から、お菓子ができる。
それが、私のお仕事です。
本を書いている。
いまだに[lo]の章を書いている。 1つの節を書き直してストレッチをし、 また別の節を書き直してストレッチをする。 適切な用語を探す調べものをしてストレッチ。
[lo]の章、どうにも長い。 長すぎる（ファーブルの『博物誌』みたい…ルナールだっけ誰だっけ）。 どうにも長すぎるねえ。 うーん、いったん頭をクールダウンしてからのほうが削るべきところを見つけやすいかも。 じゃあ、明日から[mo]の章に入ることにしようか。
とにかく[lo]の章が形になったのはうれしい。 ほかの章もこの調子でやっつけよう！
…でも今日は眠いから寝よう。
おやすみなさい、よい夢を。
本を書いている。
まだ、[lo]の章を書いている。 不要な部分を削るつもりが、どんどん増えていく。 まずいなあ。でも、まずは書いちゃおう。 それから一貫性を失わない単位でばっさり削ることにしよう。
うん、それでいいの。いいの。いいんだってば。 時間はたっぷり使うんだから。無駄に見える書き込みも、長い目では無駄にならないんだから。 先を急いでもしょうがなんだから、いいんだってば。 そうそう。いざとなったら、全部ぜーんぶはじめから書く！というくらいの気持ちで。 いつも。
それいけ！
本を書いている。
早朝の続きで[lo]の章。またまた最初から読み返し、こまごまと修正する。これはお化粧直しである。 細かい言い回しを直し、冗長な部分を削り、用語統一を心がける。 そういうことをやっていると、練習問題を思いつくのでそれをファイルの末尾にメモする。 [lo]の章半分までお化粧直しが済んだところで根気が尽きて一休み。
できあがってくると、章の構成が「当たり前」に見えてきて、 どうして最初からこの形にできなかったのかと首をかしげる。 不思議なような、不思議ではないような。
ちなみに、原稿を書くときには秀丸を使っている。 でも読み返すときには、毎回プレーンテキストをLaTeXに変換し、PDFを作っている。 きれいなフォントとレイアウトで読み返すと、エディタとは違う視点で読み返せるのでよい。 ひとむかし前のコンピュータでは、LaTeXをこまめに掛けるなんてことはとてもできなかった。 でもいまでは、一日に何十回もLaTeXを使っている。素晴らしい。ありがとう＞世の中のみなさま。
午前2時から午前4時くらいまで、[lo]の章と格闘。 格闘しているときにインタラプトされないというのはとても重要。
ほぼ決着はついた。 ちょっと「書きすぎ」の状態で最後までいったので、 あとは頭がすっきりしているときに枝刈りとお化粧直しをすれば、 [lo]の章は一区切りとなる。 まだ「大変よろしい」とはいえないが「なかなかよろしい」くらいにはなっているだろう。 もう少しで、次の章[mo]に進むことができる。長かった…。
感謝です…。
感覚としては、はじめに[lo]に盛り込もうとした内容の1/3か1/4くらいにぎゅうっと絞り込んで、 適切な例と解説でわかりやすく広げた感じ。そうすると、この章で述べるべきことがクリアになった （まだクリアさは足りないけれど）。 昨日も書いたけれど、この章の悪戦苦闘の教訓は、 頭で作り上げた内容ではなく、適切な例から必然的に流れ出てくる内容を大切にせよ ということだろう。 もっとも、悪戦苦闘の時間がなければ、よい例が見つからなかったんだけれどね。 ともあれ、この教訓は次の[mo]の章を書くときに必ず生かすようにしよう。
プログラマのダイエット31日目(8月9日でちょうどひと月)。
いま考えているnext stepは…。
礼拝から帰ってきて、また文章を読み返す。 うん、よい感じ。スタートが固まったから、その流れでうまく章が進みそうだ。 しかも、枠ぐみがしっかりしたから、軽い枝葉を乗せても大丈夫かも。 しかもしかも、形式的に説明したところでさえもvery practicalな力を帯びてきたかも。 このまま[lo]の章を走り抜けられるとよいなあ。
そうだ、昨日の午後の話を書いておこう。
昨日の午後、仕事に行く前のこと。 私は奥さんに対して度を越したからかいの言葉を投げてしまった。 奥さんは機嫌を損ねたけれど、私に対して特に反撃はしなかった。 私はそのまま仕事に出かけた。
帰り際、いつもは寄らないパソコンショップに立ち寄り、 いつもは買わないプリンタの紙を買った。 買うときに一瞬だけ「ちょっと荷物になるから買うのはやめようかな」と思ったけれど、 買った。 重くてかさばるけれど、まあ大したことはないと思った。
歩いて帰る途中、いつもと違う道を通って帰ろうとしたら、 急に雲が出てきて大粒の雨になった。 あ、まずいな、紙が濡れちゃうな、と思うまもなく、前もよく見えない土砂降りになった。 折りたたみの小さな傘を開いたけれど、まったく役に立たない。 しかも、いつもと違う道なので、帰る方向がよくわからない。
ずぶぬれで、重い荷物を抱えて、ぐるぐると道を回りながら、ふと思ったこと。
…さっき、奥さんに悪いことしちゃったな。
…申し訳なかったな。
…言い過ぎたな。
やっとのことで家にたどりつき、 ずぶぬれのまま、インターネットをしている家内のところにいって、 私は「ねえ、これって、奥さんを大事にしなさいってことかな」と言った。
奥さんは、にこにこしながら私を見て「こんな天気、めったにないのにね」と言った。
夜21時前に眠り、夜中0時過ぎに目を覚ました。 奥さんが咳をするので「お茶を持ってこようか？」と聞くと、奥さんはうなずく。 暗い中でうなずいてもしょうがないと思うのだが、気配で分かる私も私だ。 「冷たいのでいい？ あっためようか？」と聞くと、奥さんはううん、と首を振る。 暗い中で首を振ってもわからないよ、と突っ込みを入れつつ「わかった」と答える。
奥さんにお茶を持っていってから、トイレに行って体重計に乗る。 それからコンピュータを開けて、Wikiに体重を書き込む。
食卓にコンピュータを運び、昨日の原稿書きの続きをする。 原稿書きというか、原稿読みだね。 新しい文章を書くのはおっくうなものだが、以前書いた文章を読み返すのはそうでもない。 そして読み返しているうちに頭のエンジンがかかってくる。 2時間ほどかけて、昨日書いた分の何箇所かを書き直す(+131行, -131行)。 うん、書き直したところに関してはまあまあよし。 ちょっぴり、手ごたえがあった。 もしかしたら、今回の本はじめての手ごたえかも。
なかなかよろしい。感謝、感謝。
お昼はスパゲティ。
午後からマクドナルドで本の原稿書き。 今日も今日とて[lo]の章との格闘である。 ちなみに[lo]の章は（まだ）第2章なのですよ。やれやれ。
しかし、今日は[lo]の章の書き直しが非常にうまくいった。 もういちど大所高所から見直したのが功を奏した模様。 すくなくとも冒頭部分（5分の1）はすべて書き直したけれど、 いままでよりも格段によくなった。 やっぱり、いいたいことをぎゅううっと絞って、そのことにフォーカスを当てたほうがよいのだ。
それから、私の場合には「恐れ」の克服だな。大切なのは。 こういう書き方をしたら、誰か（って誰？）から怒られるんじゃないかという意識があるのだ。不思議に。 それを恐れてしまって、通りいっぺんの説明になってしまう。どこかで聞いたような説明になりがち。 そうではなく、自分の心の奥底からやってくる「これは、こうなんだよ！」という深い主張・納得の塊・物事の本質をぶちまけるほうが、ぐっと来るよな。 もちろん、後から「内なる編集者」（最近のWeb用語ですと「中の人」っていうんですか？）がトコトコやってきて、体裁は整えるのですけれど、 その前にはとりあえず、言いたいことを書いちゃうのが大事かと思います。＞自分
それから最近の発見としては、構成を考えすぎるとよくないみたい。 最初っから論理の流れを想定すると、すごく不自然になる。 全体から攻めるのではなく、詳細から攻めるほうがうまくいく。 コンセプトから攻めるのではなく例から攻める。 実例は嘘をつかない。 よい例を見つけ出し、それを提示し、ていねいに（愛をもって）読者に「何か」を伝えようとしてみる。 すると自然に（＝理由は説明できないけれど）、適切な順序で言葉を見つけることができそうだ。 構成から先に考えると、余計な（興味深いけれど、当座の役には立たない）話題ばかりがメモとして累積してしまうようだ。 なまじっか興味深いだけに、削除するのがしのびなくて、かえって害をなす。
まとめよう。
あれ？
あれれ？
こういうの、以前にも書いているぞ…。
（ごそごそ）
これだ。
ちょっと違うけどね。
最近、＠ITの掲示板で技術的な質問とその回答をめぐって騒動があり、 いろんな日記やブログで取り上げられています。 こういう騒動は珍しいことではなく、毎日のようにネットのあちこちで起こっています。
結城は以前 「技術系メーリングリストで質問するときのパターン・ランゲージ」 という文章を書いて、質問者の便宜をはかると共に、 回答者の労力軽減になることを期待しました。 感謝なことに、上記のページは多くの方からリンクされ、愛用されています。 でも、それはそれとして、やっぱり毎日のように騒動は起こるわけです。
私自身は、MLや掲示板で回答するときには、 それを「自分のこと」として考えるのが好きです。
相手の質問の仕方については上記の 「技術系メーリングリストで質問するときのパターン・ランゲージ」のURLをさりげなく示しておくのが便利です。 へたに相手を諭す文章を書くとかえって質問者の気持ちをさかなでして逆効果だからです。
質問の内容に関しては、 自分がその回答を準備するプロセスを「自分の勉強の機会」とみなすのが好きです。 質問に答える（答えようとする）のは自分の学習を深めるいい方法だと思っています。 自分が答えられそうな質問があったら、最新情報をちょっと調べて答えを考えてみる。 すると、自分の知識が意外に古いことを発見したり、よりよい解決法を見つけたりすることもあります。
質問者に不快感を与えずに、なおかつ必要な情報を引き出し、 適切な情報を返信する、というのは非常に勉強になります。 そして、そのような「オンラインのコミュニケーション力」というのは、 現代に必要とされている能力だと思います。
そういう意味で、回答者が質問者の役に立つだけではなく、 質問者は（回答者の心がけ次第で）回答者の役に立つことができると思っています。 ネットワークのコミュニティは、参加者の心がけ１つで、参加者自身が大きな恩恵を受ける可能性のある場なのです。
つまりはネットの活動は、 「相手のため」にやっているのではなく「自分のため」にやっている、と思うことにする。 そう思えないときは、何もしない。 それが精神衛生上、とてもよい態度だと思っています。 少なくとも、私はそう思っています。
（ここにちょっと逆説があっておもしろいですね。 つまり、自分の利益をほんとうに追求するなら平和が訪れ、 相手のためによかれと思ってやると騒動が起こる。 …ことがある）
ところで、話はずれますが、 私は常々、ネットワークのコミュニケーションで最も大事なのは、 「語るべき時に語り、黙すべき時に黙す」ではないかと思っています。 特に後半。 なにかひとこと言い返したいときであっても「黙る」というのはエネルギーをとても使いますけれど、とても大事。
騒動が起きた時、場が荒れるのは多くの人が余計なことを語りすぎるからです。 騒動の当事者も熱くなってしまって、 「最後に一言だけ言っておきますが」 「これを最後にもう書くのをやめますが」 といいつつ、語るのをやめられない。 「いままで黙っていましたが、一言だけ言わせてもらいましょう」となってしまう。 最後の一言を「相手」に取られると負けたようなくやしい気分になるからかもしれません。 これでは、軍拡競争のようなものですね。
自分が誤解されたり、自分に不当な言葉が投げかけられたとき、 適切なタイミングで黙する技術（あるいは、心の強さ） を身につけるのは難しいものだと思います。
最後に、覚えておく価値がある教訓を1つ。 ネットに出す文章は、よく読み返すこと。 公にされるその文章は、今後何年も、何十年も、もしかしたら何百年も、残るかもしれないんですよね。
本を書いている。
どうにもこうにも[lo]の章が固まらないので、もうずっと格闘である。 ちょっと気を緩めるとものすごい分量になってしまうし、 引き締めすぎると表面をなでただけのつまらないお話になる。
ん、もう！！
毎日、毎日、
「この章で私は何を言いたいんだろう、何を書きたいんだろう、何を伝えたいんだろう」
と自分に本気で問わなくちゃいけない。祈りつつ、祈りつつだ。 「あれも、これも、あったほうが何となくよいなあ」や「こう書いたほうが自分がcleverに見えそうだ」という気持ちは蹴飛ばすんだ。
どんどん書いて、どんどん削る。どんどん書いて、どんどん削る。
考えたことは全部ぶちこんで、本当に必要なもの以外はばっさり捨てちゃう。 そうやってぐちゃぐちゃやった後で、あの人に伝えたい何かが残っているなら、 それを大切に大切に磨き、光らせていこう。
ぎゃーぎゃー言いながら書いている。 毎回、新しい本を書くのは新しいチャレンジだなあ。 やれやれ…。といいつつも、本人は楽しんでいるらしいけれどね。
自分の中の「恐れ」（うまく書けないんじゃないか、破綻するんじゃないか）を蹴飛ばし、 自分の中の「おごり」（へへへ絶対にうまくいくぜ。どんなもんだい）を蹴飛ばし、 ていねいに、淡々と、大胆に、細心に、精密機械のように、草原を渡るすがすがしい風のように、 言葉をつむいでいきたい。
本を書いている。
最近、ふと思い立って『クリエイティヴ・ライティング』を読み返してみた。 この本は読むたびにとても元気になる。元気になるだけではなく、どんどん文章を書きたくなる。 もう何十回も読んでいるけれど、飽きない（短期間で繰り返して読もうとは思わないが）。 私が「文章を書く心がけ」という文章を書いたのは、たぶんこの本を最初に読んだころじゃなかっただろうか。
プログラマのダイエット25日目。
ちなみに、2004-08-04 22:00 現在、 Googleで「プログラマのダイエット」を検索すると58件。
以下は、Googleで見つかったページ数箇所への逆リンク。
Googleで「標準体重」を検索すると、BMI(Body Mass Index)というものが見つかったりする。 ふむふむ。
肥満度・標準体重・必要カロリー判定や、 肥満度チェックなどというものも見つかる。 これらのページによると、
BMI ＝ 体重(kg) ÷ (身長(m)×身長(m))
標準体重 = 22 × 身長(m) × 身長(m)
らしい。
BMIは22が標準だが現在の私は23なので、やはりちょっと体重多目かな。 まあ、淡々と体重計測してストレッチしていくことにしよう。
後日談： Spiegelさんから、 BMIの数値はあまり厳密に気にしすぎないほうがよいですよ、というメールをいただきました。 ありがとうございます。
本を書いている。
[lo]の章。 材料はファイルに突っ込んであるので、 あとは書けばよいだけ…のはずなのだけれど、 難しいものですね。 材料を見渡すときにはたくさんのことを頭に入れているけれど、 実際に書くときには、たくさんの材料のことをいったん忘れ、 1つの例題に集中しなくては書けない。 この「忘れる」っていうのが難しい。気が散っちゃうから。 意識的に頭のクロックを落とそう。ゆっくりタイプするのがよいかも。
クロックダウンという技法。
2004年1月の日記ダイジェストを公開。
ところで、日記ダイジェストだけですでに600ページ以上になったので、 日記ダイジェストダイジェストが必要かも…。
Truthさんという方の「あかし」をご紹介します。
おはようございます。
今日も淡々と体重を測定する。 少しずつ、ほんの少しずつ体重が減っていくのが楽しい。 プログラマのダイエットは楽だ。 夜お酒を飲まないようにして、毎日体重を量っている限り、 好きなものを好きなだけ食べてよい、と自分には言い聞かせている。 でもやっぱりちょっと意識する。 その「ちょっとだけの意識」がダイエットには重要らしい。
さて。避暑も終わり、今日も淡々と本を書く。
ディスクを整理していたら、短文のファイルがいろいろ出てきた。 昔のエイプリルフールの没ネタや日記に書こうと思って書きかけた文章の断片などである。 捨てるのもしのびないので（貧乏性）、以下、公開してみる。
殺されたスパイの手にはプログラムのソースリストが握り締められていた。 ダイイングメッセージだ。犯人は誰だ？
DEC SI
PUSH BX
INC CX
INC SP
DEC CX
INC SP
没理由：簡単すぎ。 あえて、解答したい方はこちらから。
チューリングの停止問題の対偶を利用すればタイムマシンを作ることができる。 不確定性原理で、Δxを小さくしてΔpを大きくすることに似ている。プランク定数を逆手に取るのだ。
没理由：前半では話が作れなかった(もちろんタイムマシンも作れない)。後半はこないだ グリーン博士で使った。
時刻をIDにするのは楽だ。 でもあとでその内容を書き換えるときに心理的に抵抗がある。 IDが時刻に見えてしまうから。
適当な日本語をエンコードしてIDにするのも楽。 でも長くなりすぎるし、あとでタイトルが変えられなくなる。
WikiNameをIDにするのもよい。 でもいつも適切なWikiNameを思いつくとは限らない。 JournalとしてWikiNameを使うのはあまり賢くないような気がする。 ブログをJournalとして使うときもタイトルには悩む。
思いつきのメモを書いていくときのIDは時刻が最も楽。 何を書こうとしているのか書くまでわからないけれど、時刻は決まっているから。
Abstract FactoryパターンとFactory Methodパターンは似ているけれど違う。 どちらのパターンも、生成する実際のオブジェクトのクラスを利用者から隠している。 Abstract Factoryパターンを実現するときにFactory Methodパターンを使うことも多い。 でも、Factory Methodパターンを使わなくてもAbstract Factoryパターンは構成できる。 Abstract Factoryパターンの方がFactory Methodパターンよりも「大きい」。 Abstract Factoryパターンでは、Productが複数種類登場するが、 Factory Methodパターンでは、Productは一種類。 Factory MethodパターンはFactoryの作り方を表しているが、 Abstract Factoryパターンの方は、Factoryそのものがまず抽象化されている。
フリーの作品が広まると粗製濫造のコラボレーション作品が出回るから、 著作権が強化されていたほうがよい作品ができるという意見がある。 でも、すべての作品がディズニー色になってしまう危険というものもある。 「よい作品」というのはひとつの次元では計れないのだ。
子供が何かを父親に願ったとき、 「何でもその通りに与える」のはよい父親でしょうか。
子供が何かを父親に願ったとき、 「何でもすぐに与える」のは愛深い父親でしょうか。
——違いますよね。
親は、子供の願いごとを聞くのは決して嫌いではありません。 でも、それを機械的にかなえるのが親ではありません。 愛深い親ならば、子供の意向に耳を傾けつつも、 本当によいものを適切なタイミングで子供に与えるでしょう。 時には子供があたかも自分の手でつかんだように装ってそっと与えるかもしれません。
親が子供の願いをかなえるだけでは 子供は本当によいものを得ることはできません。 本当によいものを得るためには、 親と子供の間に対話が必要です。 子供の悩みや必要や訴えを親が聞き、 親が適切なアドバイスを与える（そして対話を通して親は子供を温かく受け入れる）。 そして子供はその親からの愛を受けて、親のアドバイスに耳を傾ける。 その方法は、マニュアルがあるわけではない。 状況に応じて大きく変化する「何か」です。 子供は、自分の願いを押し通すだけではなく、 本当に大事なことは何だろうということを思いながら、 親の声に耳を傾ける。
ずいぶん以前の話。
いたずらなのか、何なのかわからないけれど、 差出人のメールアドレスが結城のメールになっている、 「出会い系の女の子風のメール」 が飛び交っていたことがある。
この結果として、その「女の子」に対して「男の子」たちからのお返事メールが、
結城のところにやってきていたことがある… (^_^; 。
ぜんぶPOPFileでspam認定されるから、
私としては問題はないんですけれど…。
ねえ「男の子」たちよ…。 「女の子」の甘い言葉のメールに引っかかってはいけないよ…。
質問
神さまが「わたし」を愛していることはどうやってわかるのですか？
お返事
私の場合でいえば、一番大きいのは聖書を読んでいて、でしょうか。 聖書に書かれていること、たとえば新約聖書を読んでいて、 「この言葉は、ほかならぬ私に向けていま語られている」 と思うときがあります。 よく聖書は神さまからのラブレターだと言われますが、 そういうことだと思います。
（以上は非常に話を単純化して書いていますのでご注意）
たとえば、誰かとメールのやりとりをしていて、
「ああ、この人は私のことをわかってくれているなあ」
と思う時ってありますよね（逆もあるかもしれないけれど(^_^;）。
聖書を読むとき、あるいは教会でメッセージを聞くときもにています。 聞きながら、私は、
「ああ、神さまは人間のこと——私のこと——をよくわかっているなあ」
と思います。そしてはっと気がつきます。 そうだ、そうだった。神さまが人間をお創りになったのだから わかっているのは当然だということに。
聖書を読んでいると、自分の心にぐさっと来て痛いときもあるのですが、 逆にまたそれを通して、 神さまは「いまのわたし」を気にかけてくださっているのだなと思うんです。 気にかけるというのは弱すぎる表現ですが。
神さまはわたしを——そして、あなたのことを——こよなく愛しています。 わたしはそれを心から確信しています。 ほかの人と交換不可能な形で。 スペシャルな存在として。
○ ○ ○
私は「聖書に書かれている神さまがほんとうだとすると、 神さまはどんなことをなさるだろうか」とよく思います。 それは特に、自分の子供に親として接するときに思います。
親としては子供に「こうやってほしい」「こういう風に成長してほしい」 と思って、いろいろ言ったり、示したりするのだけれど、 子供には子供の論理があって、なかなか親の言うことはきかない。 そういうとき、「あ、神さまも私に対して同じことをなさっているのかなあ」 と思うのです。
つまり、
自分 − 自分の子供 の関係から、 神さま − 自分 を類推するのです。
旧約聖書を読んでいると、しつこいくらいに人間は神さまを裏切ります。 一時期は「神さまの言うことをきいてちゃんと生きよう」とするんだけれど、 すぐに自分勝手に生きようとしてしまう。 そういう記事がたくさん出てきます。 自分自身の自分勝手さと重ね合わせたりしたりなんかして。
新約聖書に入ると、イエスさまというかたちをとってくださって、 神さまのほうから私たちのレベルまで降りてくださる。 そして具体的に人間の姿になって「生き方のお手本」を示してくださる。
もちろんそのお手本の通りは生きられないんだけれど、方向は理解できる。 そして、その方向に進むとき、神さまは大きく私たちを支えてくださる。 その方向が「愛」の方向だと思っています。 で、人間は自分勝手なのでしょっちゅう「愛」をねじまげてしまう。 人のためといいつつ、自分のために行動しちゃう。
神さまはそういう私たち人間のことをよくご存知で、 イエスさまの十字架の救いを備えてくださったし、 聖書を与えてくださったし…。 神さまの配慮というか、備えというのはすごい、と私は思っています。
自分の生きてきた時を振り返ってみると、 その都度その都度自分の希望ってあったわけですよ。 「こうなってほしいな」「これは絶対やだな」という風に。 でも、その自分の希望は希望として神様に伝えたうえで、 「あなた（神さま）は最善をしてくださる方ですから、あなたの考えの通りになさってください」 のように【いったん自分の手から放す】と、 すごいことを神さまがなしてくださるように感じます。 で、そういう態度はしばしば「委ねる」と呼ばれます。
つまりは、自分の人生をコントロールするのは誰か、 という問いに関係してくるわけですね。
ということです。
まとまりませんが、このへんで。 偉そうな話ばかり書いてごめんなさい。 よい道が見出されますように。
次男「ねえおかあさん。」
家内「なあに。」
次男「よるにね、ねむっているとき、のどがかわいたぁ、っていったらねえ。」
家内「うん。」
次男「おとうさんが、おちゃもってきてくれたんだよ。」
家内「そう。よかったわね。」
次男「おとうさんって、まだまだちからもち！」
家内「そう（？）」
次男「でも、おこるときもあるんだよ。」
家内「それは○○ちゃんがよくないことしたときでしょ。」
「脳内仮想キャンプ」シリーズを「夢の中の対話」というコーナーに移しました。 「はてな」は書きやすくてコメントももらいやすかったけれど、 ファイルを手元で整えるという感覚のほうが私にはしっくりくるようです。
こちらの日記を休んでいる間「脳内仮想キャンプ」で避暑(?)をしておりました。 いつもと違う雰囲気の文章になりました（いや、いつもと同じ？）。
文章はそのうちに整理してhatenaからhyuki.comへ移すことになるかもしれません。 [DIG]か、 [STORY]かどちらかになるでしょう→結局 [VTALK]になりました。
あなたのご意見・感想をお送りください。 あなたの一言が大きなはげみとなりますので、どんなことでもどうぞ。