みかままさんの、 pimlというパターン記述用のDTD (SGML) を見ているうちに、私も書いてみたくなり、 「Alexanderのパターン記述用DTD(実験版)」 を作ってみました。
DTDだけあってもしょうがないので、以前書いた 「絵本を読むときのパターン・ランゲージ」 をそのDTDで書いてみました。 RelaxerやXML Schemaでも書いてみたい…。 それからXSLTでスタイルも書いてみたい…。 時間がない…。
XMLやDTDの記述でおかしな部分があったらご指摘を歓迎します。
なお、 「絵本を読むときのパターン・ランゲージ」 は読者からのフィードバックを除いてGPLとしました。
Amazon.co.jpの本紹介のページから、 ISBN近辺をCopyし、標準入力へPasteすると(最後はCTRL+D for UNIX, CTRL+Z for Win32)、 LWP::Simpleを使ってページをゲットして、 タイトルと著者名を構成し、さらにアソシエイトのリンクまで作って表示するスクリプト。 以下では、私のID wwwhyukcomhir-22 が埋め込まれているので、 利用する人は適宜代えてください。
use LWP::Simple;
use strict;
use vars qw($page $id $isbn $geturl $content $authors @authors $booktitle $url $texturl);
# Associate Program ID.
$id = 'wwwhyukcomhir-22';
# Get HTML text from user.
print "Enter roughly copied page from Amazon.co.jp (including ISBN number):\n";
$page = join('', <STDIN>);
# Extract $isbn.
$page =~ /(ISBN:.*?;)/s;
$isbn = $1;
$isbn =~ s/[^\dXx]//g;
# Get $content.
$texturl = "http://www.amazon.co.jp/exec/obidos/ASIN/$isbn/t/";
$content = get($texturl);
# Get $booktitle.
$content =~ m|<title>(.*?)</title>|is;
$booktitle = $1;
$booktitle =~ s/\s*Amazon.co.jp:\s*本[^:]+?:\s*//;
# Get $authors.
while ($content =~ m|field-author=[^>]+>([^<]+)</a>|g) {
push(@authors, $1);
}
$authors = join(', ', @authors);
# Create $url.
$url = "http://www.amazon.co.jp/exec/obidos/ASIN/$isbn/$id/";
# Print result.
print "◆『$booktitle』", "\n";
print $url, "\n";
print " ---- $authors", "\n";
『Java言語で学ぶデザインパターン入門』のページからISBNを含む部分をコピー＆ペーストしてみた結果。
C:\WORK> perl amazonlink.pl
Enter roughly copied page from Amazon.co.jp (including ISBN number):
ブリッシング ; ISBN: 4797316462 ; サイズ(cm): 24 x 19 ←これを入力(Paste)
^Z ←終わりのしるし
◆『Java言語で学ぶデザインパターン入門』 ←以下の3行を表示
http://www.amazon.co.jp/exec/obidos/ASIN/4797316462/wwwhyukcomhir-22/
---- 結城 浩
私はこれをMakeWebの入力ファイルの形式に利用しています。 以下のような感じ。
>- 『Java言語で学ぶデザインパターン入門』
http://www.amazon.co.jp/exec/obidos/ASIN/4797316462/wwwhyukcomhir-22/
---- 結城 浩
[DP/2] 淡々と仕事。 序章を分割したけれど、分割した部分はまだ太りぎみ。 でも、何回も読み返して内容はましになったかな。 あれもこれも盛り込もうとしたくなる気持ちと、 できるだけシンプルにまとめたいという気持ちがいろいろ交錯。 気分を変えて何度も読むのがいいのかもしれない。
それにしても、Doug Lea先生の "Concurrent Programming in Java, Design Principles and patterns, Second Edition" は奥が深い本だ。 とっつきにくいけれど、歯ごたえありという感じがする。 こういう感覚はGoF本と似ているように思う。
Javaのマルチスレッドはシンプルでいいけれど、不満に感じる部分もなくはない。 Holubの"Taming Java Threads"の最終章(もしも自分が王様だったら)には、 Javaのマルチスレッドのまずい部分がまとめられている。
読者からの質問
最近自分のことを【あつくないなぁ】と思っていました。 そこで初心にかえろうと、このページ(教えるときの心がけ)にたまたまたどりつきました。 これまでの自分、最近の自分を省み、自分を振り返るのに大変参考になったと思います。 あと、もしできれば、なのですが、生徒のためを思って忠告などをする際の、 あなた様の考えを教えていただけたら、と思いました。 最後になりましたが、ありがとうございました。 （塾講師）
結城からの返事
フィードバックを感謝します。 私は「気持ちは教師」ですが、実際に生徒に教えたことはないのです…でも、思うところを書きます。 「生徒に忠告する場合のポイント」は2点あると思います。
1つは 「愛をもって真理を語る」 ということ。 これは、相手の欠点やまずい部分だけにフォーカスをあてて突き放すのではなく、 きちんと「あなたを受け入れていますよ」という態度を相手に示しつつ語るということです。 たとえ相手のまずいところが確かにまずいところだとしても （つまり、先生の言う言葉が真理だとしても）、 相手を受け入れる愛がなければその忠告はよくない、と思います。
もう1つは 「忠告は、人前では行わない」 ということ。 つまり、生徒が他の生徒の前で「恥をかく」という状況を作らないということです。 人前では明示的にほめる方がよいと思います。 以上、勝手ながら思うところを書きました。 何かの参考になれば幸いです。
「教える」という仕事はとても大切な仕事です。 あなたのお仕事の上に神さまの祝福がいつもありますように。
[DP/2] 一応順調。 しかし、序章が際限なく長くなるのは何とかならんのか ＞ 自分。
[DP/2] 今日までで、 レビューアにはNo.000〜No.004の5通を送付。 反応がいろいろで楽しい。感謝、感謝。
ネットでプログラミングを楽しむ新しい企画を思いついてページの準備。 でもまだうまい例が作れないので保留中。
午前中は礼拝。お昼は昼寝。夕方から仕事。
家内のコンピュータのInternet ExplorerもSP2に上げる。
[DP/2] 章を書き進める。が、どんどん長くなって困る。 本を書くときはいつも、薄い本を書こうと思って書き始める。 けれどもなぜか、いつも予定よりも厚い本になってしまう。 『Java言語プログラミングレッスン』のときもそうだった。 いつまでたっても書きあがらないからおかしいなと思っていたら、 予定の倍くらいの厚さになっていた。それで2分冊。 短い文章を書く、というのはとても難しい作業だと思う。
レビューアからのメールもやってくる。 読んでいるととても楽しくなる。 感謝、感謝。 複数人が同じように「わかりにくい」と指摘する場所がある。 それは本当にわかりにくいのだろう。 複数人が同じ個所の読みにくさを指摘する、というのは、 レビューで毎回体験する「事実」である。 そこは何らかの対処が必要だろう（可能なら）。
でも、あるレビューアがある個所を「ここが本当にわかりやすい」といい、 別のレビューアが同じ個所を「ここが本当にわかりにくい」という場合もある。 そういう個所はどう判断すればいいのだろうか。 一言で言えばケース・バイ・ケース、場合によるのだが、 たぶんそこは、何らかの意味でひっかかりのあるところなのだろう。 だからもう一度著者がきちんと新たな気持ちで読んでみて、 直すなりそのままにするなり決めればよいのだろう。
オンラインレビューに関するパターン・ランゲージが書けそうだ。 でも書いていると肝心の本が遅くなるので、がまん、がまん （ああ、でも、書いてしまいそうな予感…）。 例えば、上で書いた読みにくさの指摘は「みんなが落ちる穴はふさぐべき穴」パターンと言えよう。 これはAlexanderのパターン記述で言えば二つのアスタリスク ** に値する確実さを持つ。 それから、オンラインレビューに関しては、こんなパターンも考えられる…（ああっ、以下略）。
早めに寝たので夜中に目が覚め、 ウイルスが流行っているのでInternet ExplorerをとりあえずSP2に上げる。
[EP] C MAGAZINEの連載校正。 いつも丁寧な編集作業をありがとうございます＞編集者の方々。
[DP/2] いろいろ書く。 文章を書くのって難しい。でも面白い。
[DP/2] 例によって淡々と『Java言語で学ぶデザインパターン入門』マルチスレッド編を書き進める。 疲れると、レビューアから送られてきたメールをにこにこしながら読みつつ、 そこで指摘されている問題を別ファイルにメモしていく。 楽しい、楽しい。
レビューアさんたちはそれぞれ個性があって、 メールを読んでいてとても楽しい。 短いメールも長いメールもあるけれど、それぞれにとても役に立つ。 技術的な側面から書いてくださる方もいるし、 文章のまずいところを指摘してくださる方もいる。 ここ、面白かったと書いてくださる方もいれば、 早く先が読みたいですと励ましてくださる方もいる。 私は、とってもしあわせものです。(^_^)
レビューアさんに送るときには、 完全とは言えないまでも、ある程度形になったもの、 自分としては間違いをとったつもりの原稿を送っているのだが、 間違いはしっかり含まれていて、 しかもそれを複数人のレビューアが指摘してくる…。 喜びつつも「やられた」と思うこともしばしば。 それもまた楽しき哉。
[JN] JXTAについて調べる。 JXTA Shellをインストールして動かしてみる。ふむふむ。 マニュアルを参考にして小さなプログラムを書いてみる。 ShellからHelloと入力するとHello, JXTA!と表示される。 ほほう。
package net.jxta.impl.shell.bin.Hello;
import net.jxta.impl.shell.ShellApp;
public class Hello extends ShellApp {
public int startApp(String[] args) {
println("Hello, JXTA!");
return ShellApp.appNoError;
}
public void stopApp () {
}
}
誰かの参考になっているのかどうかわからないけれど、 Amazon.co.jpアフィリエイトプログラムの状況報告。
2001年8月31日〜9月19日の20日間で、 結城のリンクをたどってアマゾンへ行ったクリック数の合計は1187でした。 ユニークビジター数は518、 注文された商品16、 この間に発送済みになったのは14冊、 紹介料の合計は1452円でした。
なんてかわいらしい、 eコマースサイト…(^_^;
Googleで「デザインパターン」を検索すると、 「ギコ猫とデザインパターン」がトップに来るのに苦笑する。 GoF catalogではなくGIKO CATalogですね。
Cakeさんから「Smalltalk言語による詩篇第148篇」が届きました。
[DP/2] 淡々と仕事。 「はじめに」を書き、レビューアへ送付準備。 ああ、とても、楽しい、楽しい！（←淡々と仕事してない）
今日文章を書いていて考えたこと。 文章を書くこと、本を書くことを何度もやっていると、 自分なりのやり方（ノウハウ・心がけ・コツ…）というものが身についてくる。 それは、インターネットなどでどんどん公開するのがよい。 人に見せるのは恥ずかしいとか、自分のテクニックが盗まれるとか、 そういうことを考えずに、どんどん公開するのがよい。 蒔いたものを刈り取るというのは聖書の原則だけれど、 それはここにもあてはまる。
少しでも、他の人のヒントや助けになるような情報を公開していると、 その情報に対しての改善案や意見などがもらえることがある。 また、そういうフィードバックがもらえないとしても、 人に公開するつもりになってまとめるのは、 自分の考えの整理にもなり、刺激にもなるのだ。 それはお金なんかには換算できないほどの大きなメリットだ。 得た情報、得た知識、得た知恵、そういうものを （あきらかに他の人の害にならない限り） どんどん公開していこう。 自分が得た、もっともよい部分を公開し、人と分かち合おう。 そうすれば、それ以上の恵みが天からやってくる。 その恵みを神さまに感謝しよう。
学生の頃、 私は自分のアイデンティティやオリジナリティについて すごく悩んだ。 どういうことをやったら「自分らしく」生きられるのだろうか、と。 でも、いまはもうあまり悩まない。 だって、無理にとっぴなことをしなくても、 自分らしさというのはあらわれるのだもの。 神さまに信頼して、神様に自分の人生をゆだねると、 不思議な恵みによって、神さまに渡した分だけ、 自分らしさを保ちつつ豊かに生きられるように思う。 何倍にもなって。 「神さまに渡した分に関しては」というところがポイントだ。 最初から自分で抱え込んでしまい「ここは私の領分」としてしまうと、 そこはだんだん腐っていくのだ。不思議なことに。
文章の話に戻ろう。 自分が必死になっていろんなことを公開しても、 やっぱり、オリジナリティは残るのである。 オリジナリティというのは盗むことは不可能だし、 譲渡することすら不可能なのだ。 だから、もう私は恐れない。 安心して、どんどん、思うことを文章に書き、 どんどん、公開する。
どうせこの世で生きる時間なんてたかが知れている。 だからその間に、 自分にできることはどんどんやってしまおう。 失敗してもいいじゃないか。 失敗したらば、やりなおせばよい。 うまくいったら、神さまに感謝すればよい。 神さまが与えてくださった命に感謝しよう。 神さまからお預かりしている命なんだもの。 惜しげもなく公開しよう。 そうすれば、公開したものを受け取った誰かが、 それをさらに豊かに展開してくれるかもしれない。 遠い未来に至るまで。
たとえ、どんなつまらない（ように思える）仕事でも、 手を抜かないで、感謝しつつ、ていねいにやっていこう。 1つ1つが人生をかたちづくるのだから。 そしてその全体が、自分自身のオリジナリティ、ということなのだ。
ドキュメント。
NAME
FileSplitter
SYNOPSIS
use FileSplitter;
split_file("textfile.txt");
DESCRIPTION
`split_file'は指定したテキストファイルに埋め込まれている
複数のテキストファイル(通常はプログラムのソースコード)を抽出する。
FILE FORMAT
`split_file'へ渡すファイルは普通のテキストファイルだが、
リスト抽出用のコマンド「◆List」と
ファイルコピー用のコマンド「◇copy」を含んでいる。
LISTING
◆List:リストのキャプション(ファイル名)
----
ここにリストが入る…
ここにリストが入る…
ここにリストが入る…
----
COPY
◇copy:コピー元のソースファイル名 コピー先のファイル名
EXAMPLE
説明の文章を書く。
説明の文章を書く。
説明の文章を書く。
◆List:Helloと表示するプログラム(../src/Sample1/Hello.java)
----
public class Hello {
public static void main(String[] args) {
Display.display("Hello");
}
}
----
説明の文章を書く。
説明の文章を書く。
説明の文章を書く。
◆List:表示用のクラス(../src/Sample1/Display.java)
----
public class Display {
public static display(String s) {
System.out.println(s);
}
}
----
説明の文章を書く。
説明の文章を書く。
説明の文章を書く。
◇copy:../src/Sample1/Display.java ../src/Sample2/Display.java
◆List:Niceと表示するプログラム(../src/Sample2/Nice.java)
----
public class Hello {
public static void main(String[] args) {
Display.display("Nice");
}
}
----
以上のファイルを`split_file'にかけると、
../src/Sample1/Hello.java
../src/Sample1/Display.java
../src/Sample2/Nice.java
../src/Sample2/Display.java
という4つのファイルが作られる。
../src/Sample1/Display.java
../src/Sample2/Display.java
は同じファイルである。
AUTHOR
Copyright (C) 2000,2001 by Hiroshi Yuki. 結城浩 <hyuki@hyuki.com>
https://www.hyuki.com/
This program is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
スクリプト。
package FileSplitter;
require Exporter;
use vars qw($VERSION @ISA);
@ISA = qw(Exporter);
@EXPORT = qw(split_file);
use strict;
use File::Copy;
use File::Path;
use File::Basename;
$VERSION = '0.01';
sub split_file {
my ($textfilename) = @_;
my ($line);
local (*FILE, *OUT);
unless (open(FILE, $textfilename)) {
warn "$textfilename:$!";
return 0;
}
my $indoc = 1;
while (defined($line = <FILE>)) {
if ($indoc) {
if ($line =~ /^◆List:(.*?)\((.*)\)/) {
my ($caption, $filename) = ($1, $2);
print "Extract $filename\n";
$indoc = 0;
$line = <FILE>;
unless ($line =~ /^----$/) {
warn "Missing '----'\n";
return 0;
}
my ($base, $path, $type) = fileparse($filename);
mkpath([ $path ], 1, 0700);
unless (open(OUT, "> $filename")) {
warn "$!:$filename\n";
return 0;
}
} elsif ($line =~ /^◇copy:(\S+)\s+(\S+)/) {
print "Copy $1\n to $2\n";
my ($fromname, $filename) = ($1, $2);
my ($base, $path, $type) = fileparse($filename);
mkpath([ $path ], 1, 0700);
copy($fromname, $filename);
}
} else {
if ($line =~ /^----$/) {
$indoc = 1;
close(OUT);
} else {
$line = &remove_editor_comment($line);
print OUT $line;
}
}
}
close(FILE);
}
# //※から行末までは編集者向けのコメントなので削除
sub remove_editor_comment {
my ($line) = @_;
$line =~ s|\s*//※.*$||;
return $line;
}
1;
__END__
=head1 NAME
FileSplitter
=head1 SYNOPSIS
use FileSplitter;
split_file("textfile.txt");
=head1 DESCRIPTION
C<split_file>は指定したテキストファイルに埋め込まれている
複数のテキストファイル(通常はプログラムのソースコード)を抽出する。
=head1 FILE FORMAT
C<split_file>へ渡すファイルは普通のテキストファイルだが、
リスト抽出用のコマンド「◆List」と
ファイルコピー用のコマンド「◇copy」を含んでいる。
=head2 LISTING
◆List:リストのキャプション(ファイル名)
----
ここにリストが入る…
ここにリストが入る…
ここにリストが入る…
----
=head2 COPY
◇copy:コピー元のソースファイル名 コピー先のファイル名
=head1 EXAMPLE
説明の文章を書く。
説明の文章を書く。
説明の文章を書く。
◆List:Helloと表示するプログラム(../src/Sample1/Hello.java)
----
public class Hello {
public static void main(String[] args) {
Display.display("Hello");
}
}
----
説明の文章を書く。
説明の文章を書く。
説明の文章を書く。
◆List:表示用のクラス(../src/Sample1/Display.java)
----
public class Display {
public static display(String s) {
System.out.println(s);
}
}
----
説明の文章を書く。
説明の文章を書く。
説明の文章を書く。
◇copy:../src/Sample1/Display.java ../src/Sample2/Display.java
◆List:Niceと表示するプログラム(../src/Sample2/Nice.java)
----
public class Hello {
public static void main(String[] args) {
Display.display("Nice");
}
}
----
以上のファイルをC<split_file>にかけると、
../src/Sample1/Hello.java
../src/Sample1/Display.java
../src/Sample2/Nice.java
../src/Sample2/Display.java
という4つのファイルが作られる。
../src/Sample1/Display.java
../src/Sample2/Display.java
は同じファイルである。
=head1 AUTHOR
Copyright (C) 2000,2001 by Hiroshi Yuki.
結城浩 <hyuki@hyuki.com>
https://www.hyuki.com/
This program is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.
=cut
はちこさんなどが紹介なさっているVIP FAMILY Magazine掲示板は、 現在、非常に大事なメッセージを運んでいるように思います。 主がこの掲示板をお守りくださり、 また主の御用のために用いてくださいますようにと祈ります。
この掲示板を通しても主が働かれ、 一人でも多くの人がイエス・キリストの救いにあずかることができますように。
まだ、イエス・キリストを自分の救い主として受け入れていない方、 自分の身勝手を自分で何とかしようとしている方、 自分の罪を自分で清算しようとしている方、 自分の力で自分の人生を切り開こうとしている方…。 それは無駄なことです。 自分を頼みにしたり、 人間を頼みにすることはすべてむなしく終わります。 ですから、どうか、一日も早く——というか「今」——自分の罪の悔い改めの告白をし、 イエス・キリストの十字架の救いを受け入れてください。 いまこの日記を読んでいらっしゃる、 まだイエスさまを信じていらっしゃらない方の上に、 神さまが働いてくださいますように。
罪の悔い改めと、イエスさまを信じる祈りについては、 以下のリンクからたどることができます。
[PB] 早朝、『Perl言語プログラミングレッスン』入門編の増刷に関連した作業。
[DP/2] 道を歩いていると、よい例を思いついた。 実際に書いてみるとそれはあまりよい例ではなかったので没。 でもそれをヒントにして、別の、もっとよい例を思いついた。 それを元にして丁寧に書き進める。うん、なかなかいい感じ。 祈りつつ書き進めよう。 レビューアからも少しずつお返事をいただく。 とても励まされる。感謝、感謝。
一日でできることは、本当に少ししかない。 だからこそ、次の一歩を大切に。 現在こそ、永遠との接点である。 あなたに自由が差し出されるのは、現在においてのみ。 過去はすでに過ぎ、未来はまだ来ない。 あなたが何かをできるのは、現在しかない。 未来に備えつつも、現在に生きること。 愛するのも、赦すのも、喜ぶのも、祈るのも、悔い改めるのも、現在にしかできないこと。
あなたはいま、何かを恐れていますか。 あなたはいま、不安を感じていますか。 未来への恐れ、自分のこれからに対する不安、 どうなるんだろうという落ち着かない気持ち…。 そんなときには、時代が変化しても永遠に変わることのない神さまの御言葉である『聖書』を読みましょう。 聖書は、本当の神さまからあなたへの大切な愛のメッセージです。 あなたへのお手紙です。 聖書を開き、それと同時に心を神さまに開きましょう。 「主よ、しもべは聞いております。どうぞお語りください」 とへりくだった思いをもって神さまの御言葉に耳を傾けましょう。 現在こそ、永遠に変わらない神さまの御言葉に耳を傾けるときなのです。
恐れるな。わたしはあなたとともにいる。 たじろぐな。わたしがあなたの神だから。 （イザヤ41:10より）
「恐れるな。わたしはあなたとともにいる。 たじろぐな。わたしがあなたの神だから」 と、あなたを愛する主は言われる。
[DP/2] 淡々と書く。 うん、すごくいい。
本を書くとき、最初に、 本全体の構成(章立て)を考え、さらに各章の構成(節として立てる項目など)を考えるのだが、 各章の構成は、実際に章を書いてみないとしっくりこないことがある。 そしてまた、本全体の感じは、本を書いてみないとわからない。 でも、本を書くためには章立てが決まっていなければ書けないし、 章を書くためには節が…とやっていたら、いつまでたっても書けないわけだ。
ではどうするかというと、 とりあえず、何か書いてみるのである。 第一次近似としての目次や各章の構成などを、 まあとりあえず書いてみる。そしてその段階で、 じいっと書いたものを見つめて、ちょこちょこ書き直す。 そしておもむろに適当な章を書いてみたり、 練習問題を書いてみたり、前書きを書いてみたり、 図を書いてみたり。 そうやってしばらくして行き詰まったら、 また目次をじいっと見て…。 そんなことを繰り返しているうちに、 ぼんやりと、本全体の姿が浮かび上がってくる（ことを期待しよう）。
昔、ライティングの授業で学んだことを思い出す。 先生はこう言った。
「まず、封筒を取り出します。 別に封筒でなくてもいいのですが、 要するに手元にある紙をつかみます。 そしてそこに、自分が考えていること、自分が書きたい内容をどんどん書きます。 しばらく書くと、書けなくなります。 そうしたら紙をもう一度眺めます。 …そこが、あなたの出発点です」
いま、あの先生の言葉を思い出して (といっても英語だったから言葉そのものは覚えていないけど)、 あの先生はなかなか正しいことを教えてくださったのだなあと思う。
出発点は、頭の中にあるのではない。
出発点は、手元の紙に書かれた言葉の上にあるのだ。
[JN] JXTAについていろいろ調べる。 面白いけれど、まだまだあちこち細かい部分ではほころびが…。
[DP/2] 家で仕事。 レビューアからのメールは、量の多さに関わらずはげみになるなあ…。 何度も書いているけれど、マルチスレッドのプログラミングって難しいと思う。 Easy to start, hard to master.
[DP/2] 喫茶店で仕事。 レビューアとのやりとりが少しずつ始まる。 レビューアからのメールを感謝しつつ読む。 複数の視点というのはとても面白い。
以下は、はちこさんに教えていただいた、 マタイ24章の講解のページです。 終末のしるしとは何か、 そして神さまは聖書を通して私たちに「どのようにせよ」と語っているか、 が書かれています。
コンピュータセキュリティの専門家Bruce Schneierの観点から見た今回のテロ事件。
自由を制限する方向への安易な法制化の危険性を述べている。
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
夜中にふとfree.prohosting.comにいったら、 PHPが使えるということに気がつき、 PHP入門を読んで遊ぶ。 すぐに <? php ... ?> という形式がうるさく感じられて、 テキスト→PHP変換ツールをPerlで書き始める。 こんな感じ。
<html><head><title>PHPサンプル</title></head><body>
ECHO "<h1>サンプル文書<h1>"
IF strstr($HTTP_USER_AGENT,"MSIE")
<p>Internet Explorerを使っていますね。</p>
ELSE
<p>Internet Explorerを使っていませんね。</p>
ENDIF
</body>
</html>
以下のように変換される。
<html><head><title>PHPサンプル</title></head><body>
<?php echo "<h1>サンプル文書<h1>" ; ?>
<?php if ( strstr($HTTP_USER_AGENT,"MSIE") ) { ?>
<p>Internet Explorerを使っていますね。</p>
<?php } else { ?>
<p>Internet Explorerを使っていませんね。</p>
<?php } ?>
</body>
</html>
しかし、どこかにこのようなツールはすでにありそうだなあ。 ということに気がついて実験終了。 ちなみに、上記の変換を行うPerlスクリプトは…そうだ、これ、Perlクイズの題材にしよう。
もしかしたら、上記の変換はPHPでも書けるかもしれない。
[DP/2] 淡々と仕事。 あちこちの章の図を書いたり、練習問題を考えたり。
図は、当然ながら、どういう配置が読者の理解を助けるかを考えて描かなければならない。 小さな図1つでも、とっても時間がかかる。 もういやになるくらい時間がかかるよう…。 でもうまく描けるとうれしくなる。感謝、感謝。
練習問題もまた、どうやって読者の理解を助けるかを考えて作らなければならない。 問題作成者は読者を「出し抜こう」と考えてはいけない。 むしろ当たり前の問題を作るべきだ。 当たり前の問題というのは、本文の内容が理解できていれば解けるが、 理解できていなければ解けない問題のこと。 当たり前ですが、これがまた難しい。 問題作成は、ユニットテストを書くのと似ている。
でもそれだけではつまらない。 凝るなら解答を凝るべきだ。 問題を解いたとき（解こうとしたとき）読者の頭は活性化している。 そのときはもうちょっと高度な(advancedな)内容も理解しやすくなっている。 だから良質の別解を提示するのはとてもよい。 とてもよいのだが、そんな問題と解答のセットを作るのは、 とっても時間がかかる。 もういやになるくらい時間がかかるよう…。 でもうまく書けるとうれしくなる。感謝、感謝。
よい図がふんだんにある本、よい問題が解答とともに示されている本が 世の中に少ない理由がよくわかる。 そういう本は、作るのが本質的に大変なのだ。
今回の事件の救援活動を支援するための寄付を、 アメリカの赤十字(American Red Cross)に対してオンラインで送ることができます。 オンラインで送る場合にはクレジットカードが必要。 www.RedCross.orgのページ、左側の"Donate Now"をたどります。
なお、以上は情報の1つとして提供するものです。 結城は赤十字および上記サイトと特に関係があるわけではありません。 寄付をお送りになる方は、自己責任でお願いいたします。
Amazon.com経由でも送れるようです(Amazon.comへの登録が必要)。 Amazon.co.jpからもたどれます。
おや、いつのまにか、サムエルくんのアクセスカウンタが10000を越している…。
読者から、 あるゲーム会社がわざとstuffという表現を使ってから、 あえてその書き方をする人もいます、というご指摘を受けました。 情報ありがとうございます。
子どもが不安を感じていたら、 親は子どもをしっかりと抱きしめて、 子どもに対して「心を騒がせてはいけません」と語る。
妻が不安を感じていたら、 夫はその気持ちをしっかりと受け止めた上で、 妻に対して「心を騒がせてはいけません」と語る。
大きな変動があるとき、心に不安が押し寄せてくる。 けれども、私たちは、心を騒がせてはいけません。 どんなときでも、 イエスさまが私たちと共にいてくださるという御言葉を信じ、 信仰を堅く保ち、よく祈り、 愛をもって真理を語るようにしていきましょう。 それは人間の力ではできないことですから、 主に求めていきましょう。
大きな変動のあるとき、心に隙ができ、 サタンはそれに乗じてきます。 うっかりと惑わしにひっかからないようにしましょう。 いつも蛇のようにさとく、 鳩のように素直でなければなりません。 誤った判断、投げやりな行い、焦った行動に身をまかせることなく、 いつも主を見上げ、聖霊様のガイドに従い、 落ち着いて今日という一日を過ごしていきましょうね。
次男が夜中に何度も起きるので寝不足気味。
[DP/2] 図を描く。 図は感覚的に理解する手助けとなるが、 細かいところまで理屈にあわせた図を描くのは難しい。 正確に描こうとするとわかりにくくなる部分もある。
イエスさまの再臨のときや、 世の終わりには、どのような前兆がありますかと問われて、 イエスさまはこうお答えになります。
そこで、イエスは彼らに答えて言われた。 「人に惑わされないように気をつけなさい。 わたしの名を名のる者が大ぜい現われ、『私こそキリストだ。』と言って、 多くの人を惑わすでしょう。 また、戦争のことや、戦争のうわさを聞くでしょうが、 気をつけて、あわてないようにしなさい。 これらは必ず起こることです。 しかし、終わりが来たのではありません。 （マタイ24:4,5,6)
以下、終末のしるしについて、 またそのときの対処について、 終わりの日がいつであるかを知っているのは父なる神様だけであること、 などについてイエスさまはお語りになります…。
天の父なる神さま。御名を賛美します。 アメリカで大きなテロが発生し、多くの死傷者が出ました。 神さま。亡くなった方のご家族の上に、主の守りがありますように。 また傷ついた方の上に、速やかな癒しがありますように。 多くの方が不安を感じ、また実際上の困難に直面なさっています。 どうぞ主の平安が与えられ、一日も早く非常事態から復旧することができるように 助けてください。医療関係者、政府関係者、 そのほかこの事態の打開に尽力なさっている多くの人の上に 主からの知恵と力が与えられますように。 いま世界中で祈っている人たちの祈りに合わせて、 イエスさまのお名前でお祈りをいたします。 アーメン。
[DP/2] はじめの章をゆっくり読みながら校正する。 それから、あちこちの章をながめながら、全体を整える。 気が向いた部分は少し深く書く。 あるとき「ここはまずいなあ」と思ったところでも、 日をあらためて見ると「ん、まあいいかも」と思えてくるから不思議。 そのように評価できるのは、まがりなりにも「書いてある」からだろう。 書いてあれば「よい」や「わるい」と言える。 「いまはわるいと思っているが、また後で読み直してみよう」と考えられる。 だから、後のことはあまり考えず、 いま頭にあることをとっとと吐き出してしまうのはよい習慣だと思う。 あとで全部書き直しになってもいいのだ。たいした手間じゃない。 それに、いま書いたものにまずいところが後で見つかったとしても、 同じような失敗を読者もするかもしれない。 そしたら、そこがまた解説すべきポイントの1つとなるわけだ。 人生に無駄はない。 無駄なように思えても、神さまの手にかかれば万事が益になる。
さまざまなことが、世界中で起こる。 けれども心を騒がせず、主に信頼してよく祈らなければ。
hyuki.comのドメインの契約延長をしなければならないので、 ISPに問い合わせなど。
Googleなどで探すとけっこう見つかる間違いの例。 「掲示版」（正しくは掲示板） 「stuff募集中」（正しくはstaff募集中。stuffは詰め物） 「plogram files」（正しくはprogram files）
アマゾンから届いた "A Pattern Approach to Interaction Design" をぱらぱらと読む。 音楽のパターンランゲージ（ソロパートが楽器を渡り歩くパターンなど）、 Webサイトのユーザナビゲーションのパターンランゲージ（いつでも終了できるようにするパターンや、 メニューの階層の深さはXX個までというパターンなど）が記述されているようだ。 音楽のパターンランゲージは、 Alexanderのパターン記述に近い表記法を使っている。
そういえば、bk1.co.jpの方のアフィリエイトにも参加していたのであった。 ええと…一ヶ月で216ポイント(ポイント=円)でした。
ある人から、 「多忙のため、レビューアには申し込みませんが、応援しています」 というメールをいただいて、とても嬉しい。
クラスをfinalにすると、メソッドはオーバーライドできないが、 本当にfinalになっているわけではない、という話題。 Reflection APIは、身上調査のAPI。
import java.lang.reflect.*;
final class c {
public final void finalMethod() { }
public void notFinalMethod() { }
public static void main(String[] args) {
Method[] m = c.class.getMethods();
for (int i = 0; i < m.length; i++) {
String fi = Modifier.isFinal(m[i].getModifiers()) ? "final" : "not final";
System.out.println(i + ": " + m[i].getName() + ", " + fi);
}
}
}
/* 実行結果
0: main, not final
1: hashCode, not final
2: wait, final
3: wait, final
4: wait, final
5: getClass, final
6: equals, not final
7: toString, not final
8: notify, final
9: notifyAll, final
10: finalMethod, final
11: notFinalMethod, not final
*/
ある人へ書いたメールから： 初心者への説明はとても難しいですよね。 結城はプログラミングの入門書ばかり書いているので そのことをいつも痛感しております。 読みやすい文章を書く黄金律の1つは、 「読者のことを考えよ」 ですね。 自分のこと、自分の説明の都合を考えるのではなく、 読み手のこと、相手のことを考える。 それはとても大切なことだと思います。
MLに流した文章から： 『銀のいす』は、しばられている王子がいましめを解いてくれと 訴える部分に感動しました。ああいう選択というのは、 私たちの人生にも（しょっちゅうはありませんが）しばしば 訪れるような気がいたします。
それと似た体験は、『ペレランドラ』の中で、 ランサムがどうやったら《女王》の堕落を防ぐことができるのかを ひとり悶々と悩むシーンを読んだときもありました。 読みながら、私自身も何かを選択する局面に立たされているような そんな気持ちがいたしました。
思いつくまま書きますと、 聖書の「エステル記」の中で、モルデカイがエステルに、 あなたがいまその地位にあるのはこのときのためなのかもしれない （うろ覚えですが）というセリフをいったときの感覚と近いものがあります。
平凡な毎日を送っている。あたりまえの、昨日に続く今日を送っている。 そのつもりだったのに、突然、今日・いま、重大な決断を迫られる。 誰にも相談できない、どんな人間的な知識も役に立たない、 そんな中で何かの選択をしなければならない。 そんな感覚に私は惹かれるのかもしれません。
[DP/2] ある章を書きながら、章の構成についてまた悩んでいる。 でも、半分、楽しんでいる。
先日、実家の母と電話で話す。 母も、それから姉も、このページを見ているらしい。*^_^*
そういえば、7歳の長男が自分のWebページを持ちたいと言い出した。 正確には「インターネットに自分の自由研究を置きたい」と言い出した。 いろいろと相談中。
ある編集者の方からメールで書籍執筆の打診を受ける。 多忙のためお断りしたのだが、 その後、興味深い情報をいろいろ交換したり。
先日、本屋さんで、自分の本が売れるところを初めて見ました。
買ったのは女性でした。 その人は、オブジェクト指向関係の本が並んでいる棚を端から順に読んでいき、 最後に平積みになっていたGoF本、結城の本に目を留めました。 GoF本の前書きを読んで値段を見、 結城の本の目次をじっくり読んで値段を見、 GoF本の中身をぱらぱらめくり、 結城の本の中身(たぶん、Abstract Factoryの章)をゆっくり読み…。 そして最後に結城の本を買って行きました。
私はその隣で、本を立ち読みしながら、 その女性のことをちらちらと見ておりました。 「買わないかなあ、買ってほしいなあ」と思いながら。
女性が結城の本をレジに持っていくとき、 よっぽど「サインしましょうか」と後ろから声をかけようかと思ったけれど、 変な人だと思われるに違いないのでやめました。
買ってくださってありがとうございます。 あなたのお役に立ちますように。
掲示板で、まなさんから更新情報CGIのバグを指摘していただいた。 調べてみると、UNIXの2001年9月9日問題に起因したバグでした。 更新日時は00:00 January 1, 1970 GMTからの秒数で管理しているのですが、 更新情報のソートを行うときに誤って「文字列で」ソートしていたのです。 正しくは「数値で」ソートしなければなりません。 文字列でのソートでも通常はうまくいくのですが、 2001年9月9日には秒数が9桁から10桁に変化し、 このため、順序が狂ってしまう可能性があるのです。 このバグが顕在化した瞬間にまなさんが発見したようです。 ご指摘、感謝します。
[EP] C MAGAZINEの原稿書きをしているうちに、都合により1つ小さなCGIを作ることになった。 そこで、 「指定したドメイン内の、Google用検索ボックスを作る」 というCGIを作ってみた。 具合がよろしいので、公開。
ちなみにGooglize!は「グーグライズ」と読みます。 GoogleでGooglizeを検索すると「自分のサイトをGoogleで検索可能にする」という意味で使われているようですね。
アマゾン・アフィリエイトクイズの答えです。 2001年8月9日〜8月30日の21日間で、 結城のリンクをたどってアマゾンへ行ったクリック数の合計は1842でした。 この間に発送済みになったのは9冊、 紹介料の合計は817円でした。
すいません、以上です。 特にオチはありません。
ちなみに、アンケート結果は以下のようになっています。 60人中15人(25%)の人が正解、ということですね。
0円
3 (5%)
1円〜99円
4 (6%)
100円〜499円
8 (13%)
500円〜999円
15 (25%)
1000円〜4999円
18 (30%)
5000円〜9999円
9 (15%)
1万円〜1万9999円
1 (1%)
2万円〜9万円
1 (1%)
10万円以上
1 (1%)
計60
日記ダイジェストを更新しました。
さて、イエスの監視人どもは、イエスをからかい、むちでたたいた。 そして目隠しをして、「言い当ててみろ。今たたいたのはだれか。」と聞いたりした。 （ルカ22:63,64）
イエスに目隠しをして「当ててみろ」と言った人はどういう気持ちだったのだろう。 何がしたかったのだろう。 イエスが神の子ならば、こういうこともできるだろう、と思って試したのか。まあそういうところもあるだろう。 どうせできないだろう、偽者め、という気持ちなのか。それもあるかも。 でも単に「試した」だけではない。わざわざ無抵抗な相手をむちでたたいたのはなぜか。 単に普段のストレスの腹いせかもしれない。それは多分にあるだろう。 たたいてたたいていじめても、誰からも文句の言われない相手が自分の前にいる。 そのとき、その相手をからかい、むちでたたく監視人。
もしかしたら、 本当にその能力があるのなら、これほどまでに痛めつけたならば、 その能力をあらわにするだろう、という気持ちもあったかもしれない。 つまり、このときイエスにあたえられた苦痛や辱めは、 「たたいている本人にとって」苦しいと想像される行いであったのだ。 これほど痛めつけられたなら（私だったら）いやだ、と感じるような痛めつけ。 こんな責めを受けたら（自分だったら）耐えられんな、というような責め。 それがイエスに対して与えられた。 いわば、責める行為の中に、責める側の弱み・悩みが表現されている。 これは「人の喜ぶことを人になせ」の裏返しだ。 「自分が苦しむだろうことを人になしている」からだ。 しかし、イエスは口答えもせず、天から天使の軍勢を送ってもらうこともなく、耐えておられた。
あなたは、いま、人を責めていますか。 人を恨んでいますか。 人につらい思いを与えていますか。 そのような行為にあなたを走らせている原因・理由を、 神さまはご存知です。 あなた自身が感じている痛み、苦しみ、弱みに悩み、 それを神さまはご存知です。 どうかそのことを、神さまの前に持ち出してください。 あなたが怒るのは正当な理由があるのかもしれない。 あなたの痛みは本当に大きいのかもしれない。 しかし、それを、あえて神さまの前に捧げましょう。 感情的な怒り、瞬間的な怒りはしかたがない部分もある。 けれど、それを持続しつづけ、自分からそれをかきたてる行いは正しいでしょうか。 どうか、あなたの痛み、苦しみ、弱みに悩みを主にあけわたし、 主からの癒しとなぐさめを受けてくださいますように。 神さまが悲しまれる行いによって、自分自身にかえって災いを招くことがないように。
彼の打ち傷によって、私たちはいやされた。 （イザヤ書 53:5より）
聖書を読むときに、単なる記事、単なる物語として読むのではなく、 そこに登場する人間は「自分の姿をあらわしているのではないか」という視点で読むと、 驚きと発見と学びのチャンスが訪れる。 心を開いて神様からの御言葉——聖書の言葉——を受け入れると、 聖霊様が解き明かしを与えてくださり、霊の目が開かれる。
聖書を読む態度…。 自分で、へりくだって「主よ、お語りください。 しもべは聞いております」というサムエル少年のような態度が大事だ。 聖書に書かれていること、聖書を通して神様が語っていることは、 ほかの誰でもない、現在の自分に対して語られているのだ、ということを理解する。 そうすると、聖書を通して私たちに与えられている救いの約束、いやしの約束が、 現在の自分のものとして受け取ることができる。
聖書の御言葉を軽んじることは、自分から聖書の約束を軽んじていることにほかならない。 聖書の御言葉を軽んじることは、長い長い時を経て、あなたの手元にやっと届けられた、 せっかくの宝物を自分からドブに捨てていることに等しい。
今日も、私たちに聖書が与えられていることを感謝しましょう！
[DP/2] 練習問題を書く。 自分で問題を作り、解く。 ときどき何かの「本質」に触ったような気がして、 足を踏み鳴らす。
[DP/2] 夜中に起き出してプログラムを書く。 マルチスレッドのプログラミングって難しい。
[DP/2] 地道にサンプルプログラムの修正。 マルチスレッドのプログラミングは、 本当に簡単なプログラムでも簡単にバグを生んでしまう。 これはなかなか難物である。
[JB] マルチスレッドのプログラムを書いているうちに、 『Java言語プログラミングレッスン』のスレッドに関する記述の誤りを見つけました。 きちんとした修正文はWebの正誤表で公開しますが、要点だけ書いておきます。
「synchronizedでロック待ちになっているスレッドはwait setに入る」 という意味の記述は誤りです。 wait setに入るのはwaitメソッドを実行したスレッドです。
読者の方に誤った情報を伝えてしまい申し訳ないことである。 ああ、恥ずかしい。
[DP/Review2] 『Java言語で学ぶデザインパターン入門』マルチスレッド編のレビューア募集を締め切りました。 多数のお申し込みを感謝します。 レビューアに申し込んだ方全員に、 レビューアをお願いするかどうかのお返事を送りました。
1997年の英国旅行でお世話になったKさんが帰国なさるとのこと。 お住まいのこと、お子さんの学校のことなど、お祈りしています。
[DP/2] 章内部の構成を微調整しながら、各章をながめたりあちこち修正したり。 それに疲れたら最初に戻って「はじめに」を書いたり。 ある章を書いているときに他の章に関連したことを思いついたら、 思いついたことをその章のファイルにメモしておく。そうすると、 将来その章を書くときに今のメモを参照することができる。 コンピュータを使って文章を書くのは本当に生産性が上がる。 場所も選ばないし、紙のメモを持ち歩く必要もないし、 そのメモがなくなる心配もない。
今回の『Java言語で学ぶデザインパターン入門』マルチスレッド編も、 書いていてとても楽しい。ときどき「なぜ、私はこんなに無知なのだろう」とか 「なぜ、私はこんなに愚かな誤りをするのだろう」というときもあるけれど、 まあいいや。祈りつつ、楽しみつつ、ね。
Doug先生の書いたコードで、どうしても理解できない部分があったので、 大胆にも(?)「これって間違いじゃありませんですか」というメールをDoug先生に出してみた。 すると半日くらいで返事がきて「間違いじゃないよ。私の本のここに書いてあるからね。 もしそこを見てもわからなかったら、気軽にまた質問してごらん」とのこと。 調べたところ、私が間違っていたことが判明。しかもしっかり本に書いてある。 うう、すみません、すみません。
しかし、Doug先生の態度はすごいなあ、と思う。 多忙なはずなのに、丁寧に答えてくれる。しかも、毎回はげましを与えてくれるのだ。 ううむ、これは見習いたい態度だなあ。 いや、一応私もそう心がけてはいるのですが…。 質問メールすべてに答えていたら本当に私の時間がなくなってしまうので…。うう。 それにしても、インターネットはありがたい。
レビューア募集は、今日が〆切。 今日の朝の時点で75人の申し込みがあります。
[PB] 『Perl言語プログラミングレッスン』入門編が増刷になるということで、 それに関する作業をする。 増刷になるのはありがたいことです。 応援してくださる読者に感謝し、恵みを与えてくださる神様に感謝します。 で、気がついたのだけれど、この本が出版されたのって今年の1月なんですね。 何だか遠い昔みたい。
[PQ/Web] Perlと言えば、SOFTBANK BOOKSのWeb連載『結城浩のPerlクイズ』も 早くもVol.30まで行こうとしています。 みなさんの応援を感謝します。 そうそう、 SOFTBANK BOOKSのWebページがリニューアルしたようですので、 みなさんぜひご訪問くださいね。
森山さんがbk1やめちゃうんですって？
『Java言語で学ぶデザインパターン入門』マルチスレッド編レビューアへの申し込みは、 今日の朝の時点で67人。〆切は9/7(金)です。申し込みはお早めに。 うれしいのは、前回のレビューアで、 今回もレビューアの申し込みをしてくださる方が複数人いらっしゃるということ。 何の報酬もないのに、やってくださるというのは、 何というか…レビューを通して何か得るものがあったから、というわけじゃないですか。 何だか、それって、とてもうれしいです。 レビューアのプロフィールを丁寧に読んでいると、 初心者に近い方もいらっしゃいますし、 結城よりもずっとずっと知識や経験が豊富な方もいらっしゃいますね。 前回に引き続き、わくわくしたひとときが過ごせそうで、いまから楽しみです。
私の父は教師です。 私が小さい頃、こんな話を聞きました。 「昔の教え子はかわいいものだ。 けれども、いま教えている子どもたちが一番かわいい」 その気持ちはとてもよくわかる。 昔書いた本はとてもかわいい。 本当にかわいい。 でも、いま書いている本が一番かわいい。
私も教師なのかもしれない。
[EP] Win32::GuiTestの小さなサンプルをperldocを元に作る。 以下のサンプルはWindowsのみで動きます(Windows2000で動作確認)。 test.txtというファイルを作り、notepadで表示しておく。 そしてそこにHello, Japanという文字列を書き込み、 5回バックスペースを入れて文字を消して、World!と入力して、改行する。
Win32::GuiTestは、PPMでインストール可能。
use Win32::GuiTest qw(FindWindowLike GetWindowText SetForegroundWindow SendKeys);
use strict;
# 前準備
system("echo. > test.txt");
system("start notepad test.txt");
sleep(1);
# ウインドウを探す
my @windows = FindWindowLike(0, "test.txt");
foreach my $win (@windows) {
print GetWindowText($win), "\n";
SetForegroundWindow($win);
SendKeys("Hello, Japan{BS}{BS}{BS}{BS}{BS}World!{ENTER}");
}
eXtreme Programmingの12のプラクティスを、自分の本を書く過程と対比させてみました。 とても一致するところと、一致しないところがあります。 12のプラクティスの項目と解説文はXP FAQのページから引用させていただきました （問題がありましたらご連絡ください）。
なお、以下では、『伽藍とバザール』のバザール方式との比較も書かれています。
「この人も、イエスといっしょにいました。」 ところが、ペテロはそれを打ち消して、 「いいえ、私はあの人を知りません。」と言った。 （ルカ22:56,57より）
ペテロはイエスさまといっしょにいました。 インマヌエルなイエスさまはペテロといっしょにいました。 でも、イエスさまがつかまった後、 ペテロは「あの人を知りません」と言いました。 ペテロは以前「主よ。ごいっしょになら、牢であろうと、 死であろうと、覚悟はできております。」と言っていました。 でも、いざ身の危険が迫った環境に置かれ、 「この人も、イエスといっしょにいました」と言われたとたん、 ペテロは「あの人を知りません」と答えてしまいました。 しかもペテロはこの後二度、 合計三度もイエスさまのことを知らないと言うことになります。
いざとなったら、こんな風になってしまうのが人間の姿。 これは本当に人間の真の姿のように思います。 いざとなったら自分の過去の言葉を否定し、 過去の自分の信念、信仰、生き方を否定する。 自分を愛してくれた存在を否定し、 自分の環境を否定し、 自分のすべてを否定する。 それほどまでに弱い人間。 でも、これが人間の、ばけの皮をはいだ姿だと思います。
イエスさまの方からペテロを見捨てることはありませんでした。 イエスさまの方からペテロを拒否したり、否定することはありませんでした。 ペテロの方からイエスさまを拒否し、 ペテロの方からイエスさまを否定したのでした。
神が人を拒否するのではない。 人が神を拒否するのだ。
「死であろうと、覚悟はできています」と宣言することができたペテロですら こうだったのですから、私たちはなおのこと、 注意して神さまにつながっていなければならないと思います。 いざとなったらくるりとひっくり返ってしまう人間に望みを置くのではなく、 いつも共にいてくださる神さまに望みを置かなければなりません。
どこかで「あなたはイエスさまといっしょにいましたか」 「イエスさまはあなたといっしょにいましたか」と問われることがあるかもしれない。 そのときに「いいえ、私はイエスさまなんて人は知りません」と答えるのではなく、 「はい、イエスさまはいつも私といっしょにいました。いまも、いっしょにいます」 と答えることができるように。神さま、私たち一人一人をお守りください。
一言祈ります。
天の父なる神さま。御名を賛美します。 聖書の御言葉が開かれるとき、聖霊様が私たちの上に知恵を与えてくださり、 必要に応じた解き明かしがあることを信じ、感謝します。 どうぞ、弱い私たちをあわれんでくださり、 神さまを否む状況に陥ることがないようにお守りください。 「はい、イエスさまはいつも私とともにいます」 といつも告白することができるように、助けてください。 学校や職場、地域の活動、家庭の中にある兄弟姉妹のことを思います。 いつもイエスさまが兄弟姉妹と共にいてくださり、力を与えてくださることを感謝します。 思いがけないときに、イエスさまを証しするチャンスが訪れますが、 そのときに、自分の思いで語るのではなく、 ただ聖霊様が導くとおりに語ることができますように。 また相手の方の言葉に耳を傾けることができますように。 主が唇に御言葉を、心に愛を与えてくださることを感謝します。 あなたが語ってくださるのですから、私たちには不安や恐れはありません。 またその結果についても、すべてあなたに委ねますから、思い煩うことがありません。 ただまっすぐに証しすることができますように。 イエスさまのお名前で祈ります。 アーメン。
[DP/2] もう一度眠って、午前中に喫茶店で仕事。 文章を少し書き、コードを整理する。練習問題も少し書く。 すごくいい。面白いなあ。なるほどなあ。
RunnableインタフェースはCommandパターンか、 という議論がJava-Houseメーリングリストのトピックスに含まれていて、 興味深く読んだ。以下は、メーリングリスト中の議論とは独立な私の考え。
Runnableインタフェース1つを取り上げた場合にはCommandパターンかどうか、 というのはあまり意味はないと思う。 Threadのインスタンスを作るときに Runnableオブジェクト(Runnableインタフェースを実装したクラスのインスタンス) を渡すこともあまりCommandパターンっぽくはない。 でも、例えば、要求に対応したRunnableオブジェクトを作ってキューに入れておき、 順にスレッドを作って実行したり、 ワーカースレッドがそれを実行したりするならCommandパターンっぽくなる。
さまざまなRunnableオブジェクトがあり、 その1つ1つは何らかの要求を表している。 それをキューに突っ込むことはmethod invocationになり、 キューから取り出して実行するのはmethod executionになる(decoupling of method invocation and method execution)。 キューから削除しちゃえば要求の実行前のキャンセルになるし、 キューの順序を変えれば要求のスケジューリングになる。
RunnableオブジェクトをConcreteStrategy役として使うことも可能だろうと思う。 パターンはドラマであり、オブジェクトは役者だ。 役者がひとりでドラマを作っているわけではない(一人芝居のSingletonは別)。 オブジェクトの相互関係・役割分担・責任分担・協調関係がパターンを作っている （もちろん、それに名前があり、フォースがあり…でないとパターンとは言えないと思うけれど）。
Commandパターン。 うまくConcreteCommand役を考えるとCompositeパターンを利用してマクロコマンドを作れる。 Runnableではどうかな。ええと、ええと。そうだそうだ、ThreadGroupがあるなあ。…API調査中…だめだ。 ThreadGroupはRunnableじゃないし、Threadをaddもできないんだ。 ん？違うな。ThreadGroupはコンテナなんだ。ThreadGroupとThreadを同一視する必要はないのか。 ちゃんとThreadGroupに対するinterruptは再帰的に(OO recursiveに)呼び出されるし。 でも、ツリー上になったThreadGroupにThreadを入れておき、 トップのThreadGroupからstartさせることはできない。 ふうむ。
[DP/2] 早めに眠って、早朝に仕事。 やっぱり文章やプログラムは「眠る前」ではなく「起きた後」に書くべきだな、と思う。 ぜんぜん仕事の質が違うんだもの。
ある章のプログラムをリファクタリングする。 マルチスレッドのリファクタリングというのは、 通常のリファクタリングとは一味違うように感じる。 synchronizationのことを考えないといけないから、 安易にメソッド移動できない(synchronizedメソッドがロックするthisが変わってしまうから)。 逆にいえば、synchronized (otherObject) { ... } というブロックが多数登場する場合には、 「リファクタリングが必要となる『匂い』」がする。 otherObjectをthisとなるように、メソッドを移動するのだ。
それはともかく、 今書いている『Java言語で学ぶデザインパターン入門』マルチスレッド編も面白い本になりそうだ。 書いていて、とても面白いから。 前回のように「な、なるほど！」と言って、足を踏み鳴らしたりなんかして。 synchronizedの意味、InterruptedExceptionの意味、 そういう普段当たり前のように感じているものを、きちんと例示しながら説明していると、 「あっ、これはこういう意味だったのか」と驚くときがある。 単に私の勉強不足という話もありますが…。 こほん、それはともかく。 そのように悟った後で、他の参考書を見ると意味がよくわかる。 「ここは、こういう風に書いてくれればもう少し早く悟れたのになあ」 などと勝手な文句を言いながら。
「本を書く」ことや「人に教える」ことというのはとても勉強になるものだ。 そこで大事なのは、自分で「わかったふりをしない」ということだ。 自分なりで構わないんだけれど「なるほど」といえる地点まできちんと考えたり、 調べたりすることが大事だ。 当たり前のことだけれど、意外にこれが難しい。 これには他の人がどうか、というのは関係がない。あくまで自分の問題。 自分が納得するまできちんと考えること。 納得したら、それをもっとも適切な方法で表現する（言葉だけではなく、図やイラストや、プログラムを使って）。 表現されたものを自分で見る。 「それは、私の納得した内容をよく表しているかな？」という観点で見る。 「私の納得した内容が読者にうまく伝わるかな？」と考える。 本を書くことは、そのような作業の繰り返しだと思っている。 そうすれば、その本は、著者の身の丈にあった本になる。 知ったかぶりでもなく、先走りもせず、 すみずみまで「ええ、これはこういう意味です」と言える本になる。 「これは私が書いた本です」と言える本になる。 …と思っている。 学ぶ、ということはすべてそうなのかもしれないけれど。 本を書くことは教えることでもあり、学ぶことでもあるのだなあ。
ところで、なぜか知らないんですが、 レビューアの申し込みが急激に増えているんです。 日記のページビューも倍増しているし。 なぜだろう…。 ともあれ、申し込み感謝します。申し込みのメールには、すごく励まされます。 また、読者が考えていること、本書に期待することが伝わってきてとても参考になります。
『Java言語で学ぶデザインパターン入門』マルチスレッド編のレビューアへの申し込みは現在61人 （そのうち、女性は3人。前回は男性:女性が4:1くらいの比率だったが）。
[DP/2] 真面目に仕事。 本を書くのって、何でこんなに大変なのだろう。 自分が理解していることを、 言葉にするだけなのに、どうしてこんなに難しいんだろう。 きっと、よく理解していないんだな。 理解していると思っているだけなんだ。 もちろん、一通りは理解しているさ。 さもなくば面白さもわからないし、そもそも本を書きたいなどとは思わない。 でも、本を丁寧に書いているうちに、自分の理解が不足していることを痛いほど感じる。 適切な例が見つからない、というのは本質を理解していないからだ。 先日も書いたけれど「ポケットからふと取り出したようにさりげなく」って本当に難しい。 こういう話を書いているとき、私はいつも、 冬季オリンピックのフィギュアスケート（特にペア）を思い出す。 らくらくと、楽しそうに滑っている。 当然のように、まるで通り道が用意されているかのように滑っている。 靴に転ばないしかけがしてあるように。 不遜ながら、本を書くというのもそれに似ている（もしかしたらすべての表現活動はそうかな）。 本になった後は、ふんふんと読めばいいし、 そこに書かれた言葉を使っているのが当たり前のように感じる。 でもそれをゼロから（イチから、かな？）組み立てるのはえらく大変。 読む側と書く側ではこんなにも違うかと思ってしまう。 料理もそうだな。 フランス料理を作るのと、それを食べるのはずいぶん違う。 …まあいいや。もともと、誰からも強制されてるわけじゃなく、好きでやってる仕事なんだから、 ぶうぶう文句(?)を言うのは筋違いってもんだ。仕事仕事っと。
そういえば、 ある方から「個人クリスチャンサイトを検索エンジンで探していますが、 結城さんのページしか引っかかりません」というメールをいただきました。 個人クリスチャンサイトを探すなら「クリスチャンりんぐ」をたどるのがよいと思いますよ。
『Java言語で学ぶデザインパターン入門』マルチスレッド編のレビューアへの申し込みは現在48人。
読者から問い合わせがあったので補足解説します。
『Java言語で学ぶデザインパターン入門』マルチスレッド編のレビューアの申し込みには、 年齢や性別による制限・制約はありません。
先日の日記に「レビューアの申し込みは現在32人。年齢層は10代後半〜30代後半といった感じでしょうか。」と書いたのは、 その時点での年齢分布を書いただけであって、これが制限になっているわけではありません （しかも、この年齢分布は、年齢を記入していただいた方の分だけです。 年齢を記入していない方も複数人いらっしゃいます）。
レビューアの申し込みのページでも、 年齢・性別は「書かなくてもよい」としてあります。
誤解するような文章を書いてしまい、申し訳ありませんでした。
[DP/2] 第0章をゆっくり、ゆっくり書く。 うん、とてもいい感じ。 Visioで図も描く。
例を考えるのは難しい。 過不足ないサンプルプログラムを作るのは本当に難しい。 本質的に困難な仕事だと思う。 なぜ困難かというと、ちょっと油断すると、 そこで解説したい以上の情報が紛れ込むからだと思っている。 読者の気をそらす情報が紛れ込むから。 いま著者が語ろうとしている内容からはずれた何かが紛れ込む。 そして、その困難さは、意外なことに心の弱さから生まれる （この話、何度も書いているような気がするな）。 一言で言えば「簡単なことを書いたら馬鹿にされるのではないか」という恐れだ。 何かスーパーなこと、きらきら輝くような何か、人目を引き、驚かすような話、 そういうのを盛り込まなければならないような錯覚にとらわれるのだ。 その結果、てんこもりで何が大事かわからないようなサンプルができあがり、 著者の知ったかぶりが鼻につく文章ができあがる。 私は何とかしてそこから逃れたいと思っている。
自分が解説しようとしている内容が、 十分に意味のあるものなら、 解説者がどらや太鼓を鳴らさなくてもよいはずなのだ。 一度に一つのことを伝える。 本質的な部分に焦点をあて、それをよく表している例を考える。 そのためには本質的な部分は何かをよく理解している必要がある。 そしてそれを磨き上げて、でも力を入れすぎず。 あたかも、ポケットからふと取り出したかのようにさりげなく、 読者の前にそっと示すことができたなら素敵なのだけれど。
シンプルなサンプル。
私が求めているのはこれだ。
[DP/2] 淡々と（以下略）。
淡々と仕事をするのはいいんだけれど、合間におむつを変えたり、 息子たちをお風呂に入れたり、ねかしつけたりしていると、 マルチスレッドのプログラムを書いているのか、 自分がスレッドの1つになってしまったのが判然とせず、 なかなか疲れたりするのでありました。
さっきも山形浩生勝手に広報部部室をのぞいたりしていたんだけれど、 そのとき気がついたのは、結城がはじめてWikiに出会ったのは、 ここだったな、ということ。 たぶん部長の玲奈さんが設置したもの。 で、Wikiを触っているうちに、これはすごいと気がついて、 大元のCunninghamのWikiを調べはじめ、自分でもYukiWikiを作る。 で、デザインパターンだのリファクタリングだのエクストリームプログラミングだのと いうのを調べていると、その中にCunninghamさんがいて、 で気がついたのはWikiでパターンの話をやっている。 どうも私は鈍いというか気がつくのが遅いというか。 でも、面白い面白いと言いながら糸をたぐっていくと、 ちゃんとどこかで全部つながっているのがまた楽しい。 こういうのも神さまの御はからいなのだろうと思う。
自分の「これ、面白そう」という感覚は大事にするのがよいのかもしれない。 面白そう、楽しそう、何かが広がりそう、いろんな可能性がありそう… そういうものを自分なりに受け止め、自分なりに消化する。 そして自分の理解した範囲で構わないから言葉にして表現する。 そしてそれを可能な限り惜しみなく公開する。 すると、それに対してやはり同じように興味を持ってくれる人がいる。 インターネットのおかげで、そういう人とのやりとりをするのは 本当に楽になった。
自分の理解の範囲、それは完全には程遠いのだけれど、 それを表現すると、そこを足がかりにして展開してくれる別の人がいる。 それはとても大事なこと。 自分で全部を抱え込んでしまうと、それはそれでおしまい。 そうではなくて、全部外に出しちゃう。公開しちゃう。 とりあえず、これでどうだ、とオープンにしちゃう。 もしかしたらごそっと「パクられる」かもしれない。 「そんなことしか知らないのか」と馬鹿にされるかもしれない。 でも、それでも構わないんだ。 他の人に伝えるために、情報を整理したり表現を整えたりすることは、 それがそのまま自分の勉強になるから。 それは決して無駄にはならない。 そして、Wikiやデザインパターンのように、ときどき思いがけない実を結ぶのだ。
主の御名はほむべきかな。
結城のページは現在Amazon.co.jp, bk1.co.jp, books.softbank.co.jpの アフィリエイトプログラムに参加しています。 簡単に説明しますと… 結城のページの読者が、 特定のリンクをたどってオンライン書店に行き、 そこで本などを購入すると、 金額の約3%が結城に支払われるというシステムです。
読者は、興味深い本が紹介されるのを読むことができ、それをすぐ買うことができる。 紹介者は、紹介した本が売れれば収入が得られる。 書店は、あちこちのWebサイトからリンクを張ってもらえる。 …まあそういう仕組みです。
結城の日記の読者のみなさんは、 結城がときどきアマゾンにリンクを張って本の紹介をしていることをご存知だと思います。 あんな感じで本の紹介をするわけです。 クリックして書店サイトにいってもお金にはなりません。 あくまでも本などを購入してはじめてお金になります。 アマゾンでは「発送済み」になったときに紹介料が加算されます。 紹介したそのものを購入した場合には5%、 他の商品を購入した場合は3%が紹介料になります。
では、ここで問題です。(^_^)
アマゾン・アフィリエイト・クイズ!
2001年8月9日〜8月30日の21日間で、 結城のリンクをたどってアマゾンへ行ったクリック数の合計は1842でした。 では、紹介料の合計はいくらになったと思いますか？ 当てても商品はありませんが(^_^; 予想解答は↓のリンクでどうぞ。正解発表は数日後。
[DP/2] 淡々と仕事。 サンプルプログラムができたので、最初の章をゆっくりと書いてみる。 章内の構成が今ひとつよくないので、あちこち手を入れる。 何とかまとめられそうな感じだけれど。
レビューアの申し込みは現在32人。 年齢層は10代後半〜30代後半といった感じでしょうか。 (9/3追記:これは現在申し込みいただいている人の年齢分布という意味です。申し込みの年齢制限ではありません。念のため。)