2001年5月

Null Object(ナル・オブジェクト)パターンのお話をしましょう。

以下のNullOutputStreamクラスは 「writeしても実際には何も処理しない」クラスです。

NullPrintStreamクラスはNullOutputStreamクラスを使って 「printlnしても実際には何も処理しない」クラスです。

Applicationクラスは「0〜9までの整数を合計する」という 処理を行うアプリケーションです。

Mainクラスは、テスト動作用のクラスです。 オプション-dを使って起動するとデバッグプリントありになり、 -nを使って起動するとデバッグプリントなしになります。

デバッグプリントありのときはi=0〜9までの経過と結果を表示し、 なしのときは結果のみを表示します。

import java.io.*;

class NullOutputStream extends OutputStream {
    public void write(int b) {
        // Do nothing
    }
}

class NullPrintStream extends PrintStream {
    public NullPrintStream() {
        super(new NullOutputStream());
    }
}

class Application {
    private PrintStream debugout;
    public Application(PrintStream debugout) {
        this.debugout = debugout;
    }
    public void go() {
        int sum = 0;
        for (int i = 0; i < 10; i++) {
            sum += i;
            debugout.println("i = " + i);
        }
        System.out.println("sum = " + sum);
    }
}

class Main {
    public static void main(String[] args) {
        if (args.length == 0) {
            System.out.println("Usage: java Main -d         --- for debug");
            System.out.println("Usage: java Main -n         --- not for debug");
            System.exit(0);
        }
        if (args[0].equals("-d")) {
            new Application(System.out).go();
        } else {
            new Application(new NullPrintStream()).go();
        }
    }
}

重要なのは、

debugout.println("i = " + i);

の部分です。 もしもデバッグプリントの有無をフラグなどで判断するとすると、 ここは、

if (debug) {
    debugout.println("i = " + i);
}

になったり、あるいは、 デバッグプリントなしのときはdebugoutにnullを詰めることにして、

if (debugout != null) {
    debugout.println("i = " + i);
}

のように判断するでしょう。もしかしたら、 もっと大胆に、

// debugout.println("i = " + i);

のようにコメントアウトするかもしれませんね （そして、出力するときにはコメントをはずすのです…やれやれ）。

でも、このNullPrintStreamのように「同じインタフェース(API)を持ちながら、 何も処理しないクラス」を作れば、 利用する側をシンプルにすることができます。

このようなデザインパターンを、Null Objectパターンと呼びます。

このデザインパターンはBobby Woolfによって提案されました （サンプルプログラム、および解説文は結城が考えたものです）。

デザインパターン・メーリングリストは22:00現在350人の参加者…。

• デザインパターン・メーリングリスト

以下は「六百六十六」という数を恐れている方からのメールへの返信です。

結城浩です。

六百六十六というのは、 聖書の黙示録の１３章１８節に登場する 「獣」の数字が六百六十六である という記述から来ていると思います。 この文脈からは、 悪魔あるいは反キリスト的な存在を表現する数です。 ただし、黙示録そのものはとても難解であって、 さまざまな解釈があると思います。

もともと、六という数は、 聖書で「象徴的に」悪魔を表したり人間を表したりする と言われています。

しかしながら、数字は単なる数字であって、 その数字で呪われるわけでもありませんし、 害があるわけでもありません。

桜や富士山が象徴的に日本を表す場合があるように、 数字が象徴的に何かを表すことはありますが、 数字そのものを恐れる必要はありません。

あなたの上に神さまの祝福がいつもありますように。

• 笑い飛ばせ、魔法の数字

デザインパターン・メーリングリストの参加者は、320人を越す。 すごい増加率だなあ。みなさんの参加をほんとうに感謝します。

さて、コードを書きながらJUnitのお勉強。

昨日TestSuiteって何だろうと書いたが、 TestCaseクラスがLeaf役、 TestSuiteクラスがComposite役をつとめるCompositeパターンなのでした。 TestというインタフェースがComponent役をつとめています。 なるほど。

じゃあ、TestRunnerは？ TestRunnerのクラス階層はこうなっている。

• java.lang.Object
  • junit.runner.BaseTestRunner
    • junit.awtui.TestRunner
    • junit.swingui.TestRunner
    • junit.textui.TestRunner

Test, TestCase, TestSuiteがCompositeパターンになっていることから、 Testを引数とするメソッドが存在しているはずだ、と思いつつ読む。 でも、junit.runner.BaseTestRunnerにはない。 おかしいなあ。

junit.awtui.TestRunner, junit.swingui.TestRunner, junit.textui.TestRunnerにはrunがある。 …ん？でも引数が違うな。

• junit.awtui.TestRunnerでは、run(Class)。
• junit.swingtui.TestRunnerでは、run(Class)。
• junit.texttui.TestRunnerでは、run(Class)とrun(Test)。

なぜrun(Test)じゃなくrun(Class)なのかなあ。 せめてrun(TestCase)とrun(TestSuite)にしないのはなぜかなあ。 型チェックができないではないか。 junit.awtui.TestRunnerを読んでみると、 引数のClassをgetNameしてmainを呼んでいた…。 うーん。疑問は解決せず。 考えているうちに、TestCaseとTestSuiteの(instanceofを使わない)分離は意外と難しいなあと思いはじめる。

気分を変えて、 junit.textui.TestRunnerを読んでみる。runを読んでびっくり。 なるほど。aTestCaseが与えられたとき、 new TestSuite(aTestCase.class)をして「1個入りの容器」を作っちゃえばいいのか。 そうすれば「すべてはTestSuite」になる！ なるほど！ ちょっと目から鱗。 これって、ループの終わり判定に番兵を立てるのとちょっと似ているな。 『Java言語で学ぶデザインパターン入門』のCompositeパターンの章に加筆しよう！…ってもう遅いか。

でも、run(Class)になっている積極的な理由はやっぱり見出せず。

ところで、Compositeパターンってどういうのかというと、こういうのです。

この画像は、『Java言語で学ぶデザインパターン入門』のCompositeパターンの章扉になります。

• 『Java言語で学ぶデザインパターン入門』
• デザインパターン・メーリングリスト

恒例になった、サイン本購入申し込みのためのページの準備をはじめる。 案内のページと申し込み用CGIの作成。 たぶん、6月の半ばごろに申し込み開始になる予定です。 そのときには改めてご案内します。 もうちょっとお待ちください。

Googleで「デザインパターン」を検索すると、 『Java言語で学ぶデザインパターン入門』が上位に来る。 ちょっとうれしい *^_^*。

public class Rectangle {
    private int width;
    private int height;
    private int area;
    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
        this.area = width * height;
    }
    public int getWidth() {
        return width;
    }
    public int getHeight() {
        return height;
    }
    public int getArea() {
        return area;
    }
}

このRectangleクラスは、 Immutableパターン(by Mark Grand)を構成しています。 immutableとは「不変の」「変わることがない」という意味です。

Rectangleには、 内部状態(width, height, area)を変更するメソッドがありません。 ですから、Rectangleクラスのインスタンスは、 作られた後、内部状態を変更することはありません。

したがって、synchronized修飾子などで マルチスレッドによる不整合を防ぐ必要がありません。

[PQ/P] 驚き・驚き・驚きです。 先日出したメールマガジン『Perlクイズ』の解答が読者から少しずつ送られてきているのですが、 「な、なぜこの長さでそんなプログラムが書けるのだ？」 と驚愕のスクリプトがやってきています。 今回のクイズは「256バイト以内でPerlスクリプトを書いてください」というもの。 自由課題なのでさすがに解答数は少ないけれど、 結城は爆笑したり脱帽したりの連続です。 いや〜楽しいですね。

• メールマガジン『Perlクイズ』

先日のJUnitのサンプルについて石井さんから丁寧な添削とコメントをいただく。 ありがとうございます。 修正のポイントは以下。

• junit.textui.TestRunnerを使う
• runTestをオーバーライドせず、テストメソッドをpublicにする
• assertTrueの代わりに(ここでは)assertEqualsを使う

import junit.framework.*;

public class StringTest2 extends TestCase {
    private String s1;
    private String s2;

    public StringTest2(String name) {
        super(name);
    }

    protected void setUp() {
        s1 = "Hello, ";
        s2 = "JUnit.";
    }

    public void testHello() {
        String s = s1 + "World.";
        assertEquals("Test of Hello.", "Hello, World.", s);
    }

    public void testConcatenate() {
        String s = s1 + s2;
        assertEquals("Test of JUnit.", "Hello, JUnit.", s);
    }

    public void testBad() {
        String s = s1 + "hello.";
        assertEquals("Bad test", "Hello, JUnit.", s);
    }

    public static void main(String[] args) {
        junit.textui.TestRunner.run(new TestSuite(StringTest2.class));
    }
}

以下は実行結果。 assertEqualsを使っていることにより、 ちゃんと「本来こうあるべき」というexpected:が表示される。

...F
Time: 0.01
There was 1 failure:
1) testBad(StringTest2)junit.framework.AssertionFailedError: Bad test expected:<Hello, JUnit.> but was:<Hello, hello.>
        at StringTest2.testBad(StringTest2.java:28)
        at StringTest2.main(StringTest2.java:32)

FAILURES!!!
Tests run: 3,  Failures: 1,  Errors: 0

うん、いい感じですね。 石井さん、感謝します。 もっとJUnitを勉強せねば。 使い方もさることながら、自分で作ってみたいな、こういうツール。

以下は、添削してくださった石井さんのページ。

• まさーるのページ

ところで、生じた疑問。 JUnit 3.7のjavadocにはjunit.textui.TestRunnerに関するドキュメントがない。 どうしてリリースに含まれていないのかご存知の方はいらっしゃいますか？ ソースからjavadocで作れということなのかしらん。 てなことを言っててもしょうがないので、 javadocのマニュアルを読んで、 Perlでjavadocを動かすスクリプトを書く。

Perlって素敵さ♪

ちなみにjavadocのマニュアルというのは、 javadoc - The Java API Documentation Generatorのことで、 jdk1.3/docs/tooldocs/win32/javadoc.html にある(Windows版)。 日本語版もきっとどこかにあるでしょう（想像）。

いがぴょんさん から情報あり： Javadoc 1.3日本語ドキュメント

もちろん、javadocで表示されるヘルプを見てもいいけれど。

$dir = "myjavadoc";
open(PACK, "> _packs") or die;
print PACK <DATA>;
system("mkdir $dir");
system("javadoc -d $dir -sourcepath . \@_packs");
__DATA__
junit.samples
junit.samples.money
junit.tests
junit.awtui
junit.extensions
junit.framework
junit.runner
junit.swingui
junit.textui
junit.ui

jar xvf src.jarでソースを展開して、上記のスクリプトを動かして、と。 できたできた。 javadocを読む。 ふむふむ…。 ほほう…。junit.textui.TestRunnerの代わりにjunit.swingui.TestRunnerを使えばGUIでテストができそうだ。 やってみよう。

ところが、予想に反して、以下は失敗。

○ junit.textui.TestRunner.run(new TestSuite(StringTest2.class));
   ↓
× junit.swingui.TestRunner.run(new TestSuite(StringTest3.class));

理由は、 junit.swingui.TestRunner.runの引数は、 TestSuiteではなくClassだから。 以下ならOK。

○ junit.swingui.TestRunner.run(StringTest3.class);

動かしてみると以下のような画面が出てくる。 うん、いい感じですね。

以下でもうまくいくようだ。

○ junit.textui.TestRunner.run(StringTest3.class);

じゃあTestSuiteはいらないのかな？ もう少し研究してみよう。

JUnit 3.7に付属のjavadoc以外のドキュメントは、 示されている例があちこち古くなっているようだ （勉強中の身なので、厳密にどうかはわかりませんが）。

javadocは以下のほうが読みやすくなるかな。-localeオプションははじめにつけなければいけないらしい。

system("javadoc -locale en_US -windowtitle JUnit -d $dir -sourcepath . \@_packs");

デザインパターン・メーリングリストの方は、 コメントのつけ方の話題や、 エクストリームプログラミング(XP)の話題で盛況。 今日12:00で265人参加。

• デザインパターン・メーリングリスト

[DP] というわけで、『Java言語で学ぶデザインパターン入門』再校の読み合わせが無事終了。 例によって例のごとく、編集の方と一ページ一ページチェックをする。 地味だけれども大切な仕事。 仕事は地味だけれど、結城はこの「読み合わせ」がとても好き。 自分が書いた文章の間違いを指摘されたり、 「ここはなぜこうなっているのか」 「これをもう少しわかりやすい表現に」 「ここは『の』が多すぎ」 などと細かいチェックが入ったりするのが好きなのである。 編集者と同じところに朱が入っていて、互いに「ニヤリ」としたり、 大きなミスに気づいていなくて互いに驚いたり、 地味な仕事にもドラマがあり、喜びがある。

読み合わせが終わると、担当編集者は厳しいスケジュールのため編集室に戻り、 結城は編集長と打ち合わせ＋食事へ出かける。 本に関して、執筆に関して、編集に関して、文章に関して、 互いに意見を交換し、親交を深める。 デザインパターン・メーリングリストの話をしたり、 インターネットにおけるコミュニケーションの話をしたり。

つくづく「本を書く」というのは底抜けに面白い仕事だと思う。 感謝、感謝である。

• 『Java言語で学ぶデザインパターン入門』

デザインパターン・メーリングリストの参加者は23:30の時点で250人になりました。 みなさん、ありがとうございます。

• デザインパターン・メーリングリスト

今日は『Java言語で学ぶデザインパターン入門』の再校読み合わせ。楽しみ楽しみ。

昨日、デザインパターン・メーリングリストの参加者は数日中に200人を越すと書いたが、とんでもなかった。 今日の朝6:00の時点ですでに越してしまいました。 現在も増えつづけていて、8:30の時点で210人の参加者がいらっしゃいます。 perl-lesson MLの方は、200人を越すのに2ヶ月かかっていることを考えると、 この増加数はすごい、と思う。 みなさま、ご参加ありがとうございます。

現在はメーリングリスト開始時期なので、 比較的こまめにメールを書き、返事を出している。 Webページの過去ログなどを見ても、 eグループよりFreeMLの方がどうも使いやすそうである。 一番大きいのは日本語対応がしっかりしていることと、 メールに記事番号が付けられていること。 メールに記事番号をつけるというのは、 日本のMLに特有の機能らしい。

c2.comのWikiにもPatternsMailingListInJapaneseとして登録する。

• デザインパターン・メーリングリスト
• 『Java言語で学ぶデザインパターン入門』
• PatternsMailingListInJapanese

読み合わせに向けて原稿を再度チェック。 うーん、とても、とてもいい。

主なる神さま。あなたのお名前を賛美します。 あなたは素晴らしい方、あなたの御わざをほめたたえます。 土くれに過ぎないこの小さき者を愛してくださり、 あふれんばかりの恵みを与えてくださって感謝します。

この者にはその資格がありませんのに、 書くべきテーマを与えてくださり、 時間を与えてくださり、 知恵と言葉と勇気と素晴らしい助け手を与えてくださり、 ここまで導いてくださったことを心から感謝します。 自分の力では本を完成させることはできません。 主よ、あなたがはじめられたことですから、 あなたがすべての点において完成まで支えてくださることを信じます。

いま書いている本を、必要としている読者のところに届けてくださり、 必要な知識を伝えてくださいますように。 聖霊様がどうぞ助けてください。 また忙しい中で勉強している方々に助けとなりますように、 励ましと力が与えられますように。 この小さき者が感じることができた喜びを少しでも分かち合うことができますように。

この本を編集なさっている編集の方々の上にも、 必要なものすべてが与えられますように。 レビューをしてくださった方に、 この本を組版なさる方、印刷所の方、 営業の方、配送の方、書店の方、読者、そのほか多くの方の上に、 主からの祝福が豊かにありますように。 この本に関わるすべての方の上に、 主からの愛が注がれますように。 この本は技術書ではありますが、 あなたの栄光を表すものとなりますように。

すべての栄光はあなたにあることを覚えます。 主なる神さまの上に、栄光が世々限りなくありますように。 私たちの尊い救い主、イエスキリストのお名前でお祈りいたします。

アーメン。

ハレルヤ！

[JQ]の宣伝が効いたのか、 今日19時の時点で、 デザインパターン・メーリングリストの参加者は168人(!)。 数日中にはおそらく200人を越すと思われます。 少しずつまわり始めたようですね。 みなさんのご参加を感謝します。

• デザインパターン・メーリングリスト

[PQ/P]と[JQ]を発送。 デザインパターン・メーリングリストの宣伝も入れる。 今日朝の時点での参加者は76人。みなさんのご参加を感謝します。

メールマガジンを発行すると、何通か必ずエラーメールがfreeserve.ne.jpから返ってくる。 このプロバイダはメールボックスに容量制限があるようで、 「あなた様がメールを送ったfreeserveユーザーのメールボックスが制限値に達してお り、お送りになったメールを受け取ることが出来ませんでした。」と言われてしまう。 なるほど、と思った次の瞬間 「じゃあ、このユーザに『あなたのメールボックスがいっぱいですよ』って 教えるのはどうするのか？」と悩んでしまう。 「メールボックスがいっぱいですよ」というメールを出しても無意味ですからねえ。

以下、今回のメールマガジン『Perlクイズ』。

-----------------------------------------------------------
●クイズ
-----------------------------------------------------------
256バイト以内で、楽しい・興味深い・あっと驚く・美しい・便利な
Perlスクリプトを作ってください。題材自由。力作に期待。
条件は以下。

・バイト数が256バイト以内であること。
・改行は1バイトとしてカウント。
・モジュールは標準モジュールのみ利用可能。
・#! の行はカウントに入れなくてもよい。
・実際に動くものであること。
・ルールで迷う点があったら、
　「私はこう判断した」というコメントをつければ可。

以下に解答例を示します。
もちろん、解答はCGI以外でもかまいません。

◆www.hyuki.comサイト内をGoogle.comで検索するCGI(g.cgi)(230バイト)
（実際に http://www.hyuki.com/pq/g.cgi に設置してあります）

#!/usr/bin/perl
$_=$ENV{QUERY_STRING};
print"Location: http://www.google.com/search?$_+site:www.hyuki.com\n\n"if$_;
print<<'X'unless$_
Content-type: text/html

<html><form action=g.cgi><input type=text name=q><input type=submit></form>
</html>
X

• メールマガジン『Perlクイズ』

インフォシークメーリングリストの検索ページに perl-lesson MLとデザインパターン・メーリングリストを登録。 地道な宣伝活動も大事なのである。<-niko>

Web版の『Perlクイズ』Vol.23の校正を行う。 Web版では公開数日前に編集の方からメールが来て校正を行う。 校正させてもらうのは、とてもありがたい。

• Web版『Perlクイズ』

[DP/ML] デザインパターン・メーリングリストの宣伝をあちこちにする。 23時現在の参加者は59人。みなさんのご参加を感謝します。

• デザインパターン・メーリングリスト

テストツールのJUnit 3.7を試す。

1. JUnit.orgから junit3.7.zip をダウンロード。
2. unzip junit3.7.zip
3. CLASSPATHをjunit.jarに設定。
4. ドキュメントを見ながらサンプルを書く。
5. コンパイルして実行。

import junit.framework.*;

public class StringTest extends TestCase {
    private String s1;
    private String s2;

    public StringTest(String name) {
        super(name);
    }

    protected void setUp() {
        s1 = "Hello, ";
        s2 = "JUnit.";
    }

    protected void testHello() {
        String s = s1 + "World.";
        assertTrue("Test of Hello.", s.equals("Hello, World."));
    }

    protected void testConcatenate() {
        String s = s1 + s2;
        assertTrue("Test of JUnit.", s.equals("Hello, JUnit."));
    }

    protected void testBad() {
        String s = s1 + "hello.";
        assertTrue("Bad test", s.equals("Hello, JUnit."));
    }

    protected void runTest() {
        testHello();
        testConcatenate();
        testBad();
    }

    public static void main(String[] args) {
        TestSuite suite = new TestSuite();
        suite.addTest(new StringTest("Sample"));
        TestResult result = new TestResult();
        suite.run(result);
        System.out.println("runCount = " + result.runCount());
        System.out.println("errorCount = " + result.errorCount());
        System.out.println("failureCount = " + result.failureCount());
    }
}

書いていて、 junit.framework.Assertのassertメソッドがdeprecatedになっているのに気づく。 assertTrueに変更。

[DP/ML] 『Java言語で学ぶデザインパターン入門』の読者を主な対象とした、 デザインパターン・メーリングリスト[DP/ML]を開始しました。 Java、デザインパターン、オブジェクト指向に興味のある方ならどなたでも参加できます。

「読者を主な対象とした」といっても、まだ出版されていない…(^_^;

• デザインパターン・メーリングリスト

『Java言語で学ぶデザインパターン入門』再校中。 今日は編集部から索引がやってきたので、校正して返信する。 メールって便利。

『Perl言語プログラミングレッスン』入門編に合わせて perl-lesson MLというメーリングリストをたちあげたように、 『Java言語で学ぶデザインパターン入門』に合わせて メーリングリスト[DP/ML]をたちあげようと思っている。 eGroupsはいま1つ使いにくいところがある(Web上にある過去ログの表題の日本語対応が少し変。それに重い)ので、 今度はFreeMLにしようと考えている。 さてどうなりますか。

いまの予定では『Java言語で学ぶデザインパターン入門』のフォローや誤植情報入手、 それにもちろんJava、パターン、オブジェクト指向についての気軽なおしゃべりの場にしようと 思っている。

perl-lesson MLを運営していて思ったのは、 ある程度人数が集まってくれて、 いい参加者（いい読み手、いい書き手）に恵まれれば、 メーリングリスト管理者の手間というのはほとんどかからない、 ということだ。 perl-lesson MLは本当にいい感じのメーリングリストに育ってくれている。 現在280人ほどの参加者がいるけれど、 うまく参加者が互いにフォローしあっている感じがする。 参加者のみなさんには本当に感謝している。 以下は、最近perl-lesson MLに結城が流したメールの一部です。

結城浩です。

私はPerlの本を書き、Perlのメールマガジンを出し、
Perlのメーリングリストを運営していますが(^_^;
いまだにわからないことはたくさんあります。
たくさんたくさんたくさんあります。勉強の日々です。

でも、ほとんどの場合、perldocあるいは
ラクダ本（オライリーの『プログラミングPerl』）を
読むことで解決します。
Perlはドキュメントが豊富にある環境だと思います。

もしも『Perl言語プログラミングレッスン』入門編を
読んでしまい、練習問題もやってしまったならば、
ぜひオライリーの『プログラミングPerl』をお読みください。

私は朝、ひげをそっている間、あの本をはじめから読んでいきました。
毎日少しずつ読んで、わからないところには印をつけて、
とにかく全部最後まで読みます。
そうすると、どういう内容がどこに書いてあるかが把握できるように
なります。

プログラミングPerlも一通り読んだなら、
Effective Perlを強くお勧めします。非常にいい本です。
しかし、Effective Perlはある程度Perlが手になじんでないと
読みこなすのが難しいかもしれません。

プログラミング言語をどう学ぶのがいいか、
に簡単に答えることはできません。
それは人それぞれに学び方が異なるからです。

Perlの場合は、かなりの問題がプログラミングPerlや
perldocをきちんと読むことで解決します。
入門書で身に付けるのは、プログラミングPerlやperldocを
読むための基礎知識・基礎体力でしょう。
あとは実際にプログラミングをしながら、
少しずつ経験値を上げていくのでしょうね。

経験値を上げるときにいい方法の1つは、
「他の人に教える」というものです。
自分が学んだ範囲、自分がわかっていることについて、
他の人が困っていたら教える。そして教える際には、
ちょっとperldocやプログラミングPerlで確認する。
それはすごくよいことです。
自分にも勉強になるし、相手にも役に立つ。

このperl-lesson MLのようなメーリングリストは、
そのように「互いに教えあう」場として利用できると
思います。教えてもらう側だけが学ぶのではなく、
教える側も学ぶことができる場として。

私はこのperl-lesson MLでよくみなさんに
「作ったスクリプト、公開しましょうよ」とお勧めします。
それは、スクリプトを公開するのもまた自分の経験値を
上げるとてもいい方法だからです。

このperl-lesson MLに集っているみなさんの「Perlの経験値」は
さまざまでしょう。結城よりもPerlに詳しい方もたくさんいらっしゃると
思います。経験値はそれぞれ異なりますが、
みんなが自分の現在の知識を持ち寄り、
「今度、こんなスクリプト作ったよ」とアナウンスしたり、
「その部分はこう直したほうがいいよ」とアドバイスしたり…
このperl-lesson MLがそういう場になるといいなあと思います。

みなさん、いつもありがとうございます。
発言なさっている方はもちろん、ROMしている人にも感謝します。

Enjoy Perl!

• 『Java言語で学ぶデザインパターン入門』
• 『Perl言語プログラミングレッスン』入門編
• perl-lesson ML
• どのようにしたらプログラムを１から書けるようになるのでしょうか
• プログラミングを身につけるには
• プログラミングの学び方をめぐって

知らないうちに時は流れていた。 金曜日から今日まで何していたっけ。 まあいいや。

『Java言語で学ぶデザインパターン入門』の再校が編集部から送られてくる。 毎度のことだが、再校になると「ざらざら」が取れてきてとても読みやすくなっている。 しかし、間違いがゼロになっているわけではない。 あれだけチェックしてもやはり間違いは残っている。 それはさておき、原稿を読むのはとても楽しい。

例えば、www.google.comに行って、 「デザインパターン」を検索する。 それから、ページの最下部にあるGoooooogleのリンク先をたどる。

Internet Explorer 5.5だと、そのリンクから先がたどれない。 Netscape Communicator 4.75や6だと、たどれる。 これって、他の人もそうでしょうか? それとも私だけ？

[PQ] エントリは19個に増加。 みなさんよく考えるなあ。 何人かから「〆切までには送るから待ってよね！」というメールが来ました。 大丈夫です。もちろん5月18日の23:59までは待っています。 なぜ〆切があるかというと、同じスクリプト内で横並びで同時に比較したいからです。

[MAP] 翻訳再開。 第3章の第0稿を書いている。

countは、ここでは「数える」ではなく、 「count A as B」という形で「AをBと見なす」「AをBだと思う」なのだろう。 原文では最初の「要素」が0か1となっているが、 訳文では意味を考慮して「要素の添え字」と言葉を補っている。 しかしこれでは「ヒープの最初の要素の添え字」と「の」が重なってしまう。

今回のメールマガジン『Perlクイズ』は初の「スピードレース」です。 関数の実行速度を競います。 〆切は2001年5月18日23:59です。 ふるってご参加・ご応募ください。 現在、すでに8名のエントリがあります（みんな、なんて熱心なの…(^_^;　〆切は明日でもよかったなあ…）。

• メールマガジン『Perlクイズ』（バックナンバーをごらんください）

[EP] ぜいぜい。 何とか原稿を出す。 編集部のみなさんごめんなさい。 さあ、これで眠れると思い、眠る前に日記めぐりをしたのが午前5時11分。 森山さんの日記を見ると、

と書いてある。思わず勢いで「応援メール」を送ってしまう。 その後、爆睡。

起きてからメールチェックすると、思いがけず森山さんからお返事が(午前6時13分)。 無事上がったとのこと。 お互い頑張りましょう、とエール交換。

• 森山さん - 独断と偏見のＳＦ&科学書評

森山さんが発行している「ネットサイエンス・インタビュー・メール」は、 発行部数が25000以上(!)あり、「まぐまぐ」科学・技術での発行ランキング1位である。すごい。 ランキングを見ると、発行部数がダントツなのがわかる （ちなみに結城のメールマガジン『Perlクイズ』も同じランキングで10位に入っている）。

• まぐまぐウィークリーランキング / 科学・技術

『Java言語で学ぶデザインパターン入門』の初校読み合わせ。 今回はけっこう長時間だったが、無事に終了。 それに先立ち、 ソフトバンクパブリッシングの稲葉副社長さんに久しぶりにお会いする。 有益なお話をうかがい、また大きな励ましもいただいた。 感謝。

その後、食事をしながら結城が今後の仕事の方針についてプレゼンテーションをして、 編集の方から意見をいただく。率直な意見の交換の後、次の本の予定がほぼ固まる。 感謝、感謝。

例によって、 その後は編集者との濃ゆい雑談。 言葉のこと、 文章を書くこと、 本を作るということ、 「執筆」と「編集」のこと、 インターネットの文章のこと、 編集者に必要な資質のこと…。

この日記にも何度も書いているけれど、 「本を書く」というのは本当にわくわくする仕事だと思う。 何というか…チャレンジングで、エキサイティングな、 素晴らしく魅力的な仕事である。

結城はいつも「ベストセラーよりもロングセラー」を書きたいと思っている。 また、たとえそんなに売れないとしても（売れてもいいけど）、 読んだ人に喜びや励ましを与える本を書きたい。 1人でも多くの人に「なるほど！」という思いを与えるような、 何だか新しいことに挑戦したくなるような、 読者が自分でも試したくなるような、 そんな本を書きたい。

偉そうな顔をするために難しい本を書くのではなく、 難しい内容を噛み砕いて、びっくりするほど易しく、くどいほど丁寧に説明した本を書きたい。 もうすでにみんなが（ある程度）知っていることであっても、 もう一度そこに新しい光を当てるような本を書きたい。 読者がはっとして「なるほど、そういう意味だったのか！」と感じるような、 そんな本を書きたい。

知識獲得のためだけの本にはしたくない。 もちろん、必要な知識、必要な情報を読者に伝えることは最低条件だが、 それだけには終わらせたくない。 結城がその知識を身につける過程で感じた「わくわく」を伝えるような、 そんな本を書きたい。 だから、結城はいつも「自分がわくわくしながら」本を書きたい。 せっかく本を書くのだから、本当の意味で「楽しみながら」本を書きたい。

著者は本の内容と形式について全判断を行い、全責任を負う。 しかし、その栄光を自分に帰さないようにしたい。 情報や励ましを私に与えてくださった多くの人に感謝し、 高度で献身的な編集をしてくださる編集者に感謝し、 読んでくださる読者に感謝し、 そしてもちろん、天にいらっしゃる父なる神さまに感謝しなければ。

神さまが、すべてのすべてを備えてくださったのだから。

• こんな本を書きたい（毎回同じようなことを書いていますね…）
• 読み合わせ

連載原稿を書く気分転換に、メールマガジン『Perlクイズ』を発行する。 いつも思うのだが、メールマガジン発行というのは仕事なのだろうか…。 まあいいや。

• メールマガジン『Perlクイズ』

メールマガジン『Perlクイズ』には3系統あって、

[PQ]        通常の『Perlクイズ』　　　　普通
[PQ/W]      初心者向けの≪若葉マーク≫　やさしめ
[PQ/P]      実用性を考えない≪パズル≫　むずかしめ

となっています。 「問題」→「解答と次の問題」→「解答と次の問題」→…という流れが3つあるわけです。

「なんじゃこりゃ」という感じの≪パズル≫も面白いのですが、 私は≪若葉マーク≫が好き。 Perlに慣れた人なら簡単そうに見える問題なのだが、 あなどっていると間違うような問題が多い。

読者からの解答はすべて目を通しているのですが、 最近、実際に試さない人が多いことに気がつきました。 問題を読む。ははあ、これはこういう問題だな、と想像する。 そして解く。そこで安心してしまい、実際に動かすことなく解答メールを送る。 こういうパターンの人が意外に多いのです。 これは、すごくもったいないことです。 Javaのようにコンパイルが必要な言語とは違い、 Perlでは書いてすぐに試すことができるのですから。 だから、最近は実行しないとひっかかるような問題を多く出すように心がけている。

思いつくまま書き進めてみよう。 人の言うことを聞く（言うとおりにするという意味ではなく、 耳を傾けるという意味）のは意外に難しい。 書いてあることを読み取ることも難しい。 自分が思うことを言ったり書いたりするのはそれほど難しくない。 自分が言ったり書いたりしたことを相手に理解させるのは難しい。 なぜなら、相手も聞いていないからだ<-niko>。

人の言うことに耳を傾ける練習、 書かれていることを読む練習ができていると、 自分が言ったり書いたりするときに役に立つ。 まさに「話し上手は聞き上手」。 メールを書く心がけにも書いたけれど、 うまく、効果的なメールを書くコツは、メールを出す前に読み返すことだ。 そのときに、作者の帽子を脱ぎ捨て、読者の帽子をかぶる。 いったん自分が書いたことを忘れ、そのメールを読む人の気持ちになってみる。 そのメールを自分がもらったとしたら、どんな印象をもつか、 どんな情報が得られるか、どんなアクションを起こすか、 そのようなことに思いをめぐらせて読む。 メールを読み直すという習慣を持っている人は、 それがどれほど効果的かを知っている （本当にそういう習慣を持っている人は、 自然にそれを実行しているので、 読み返すという行為を意識していないかもしれない）。

• メールを書く心がけ
• 人間関係を改善するもっともよい方法

自分から情報を発信するときには、受信の練習をすること。 これは、プログラミングの学習にも、メールを書くことにも、会話にも もしかすると信仰生活にも——信仰は聞くことからはじまる——、どれにでもあてはまることかな。 自分の行動を客観視している、といってもいいかもしれない。

プログラミングの本を開く。書かれていることを読む。 自分の頭で考えることは大事だが、 その前に、目の前にある文字列を読んで「そこには何と書かれているか」を読み取ることは大事だ。 書かれていることを読み取った上で、自分の頭で考えるのだ。 そうしないと、本を開いて勉強しているようであっても、 単に自分の思い込みを強化しているだけになってしまう恐れがある。 思い込みを強化するだけ、というのは、 いわば「自分の幻想の中に生きている」ことだし、 「夢の中を歩いている」とも表現できる。 私は、いま、目覚めているだろうか。

それはさておき、 学習において「素直さ」というのは大事なポイントだと思う。 「熱心さ」や「頑張り」も大事だが、「素直さ」はとても大事。 そしてそれと共に「健全な懐疑主義」も大事。 つまり自分がわからないことをわかったふりをしない、ということだ。 ただし、わからないことがわかるまで先に進まない、というのもまずい態度だ。 だって先に進めば自然とわかることなのかもしれないから。

素直さと熱心さと健全な懐疑主義を持って学ぶのは、 主体的に学ぶ態度にもつながっていき、 自然と学習が「面白く」なっていくものかもしれない。

いろんな学習態度を考えてみよう。

自分の学習態度ってどうなっているだろう。 どうするのがよい学習なのだろう。

[JN] UNIX USER連載『Practical Java Lesson』。 Xalanを使ってXSLTの練習。

原稿が書きあがったので、初の試みとして、 原稿＆サンプルプログラムのレビューアを募集します。 以下のZIPファイルに書きあがったばかりの原稿ファイルとプログラムファイル、 XML, XSLT, DTD, GIF, VISIOファイルが全部入っています (当然ながら、Xalan-Javaは入っていません）。

どなたでも、 以下の条件を守れる方なら自由にダウンロードすることができます。 数日でこのリンクはなくなりますので、お早めに （5/12になくなりました。みなさん、感謝します）。

• ダウンロードの条件
  • ダウンロード後、一週間以内にレビュー報告を結城浩 hyuki@hyuki.com あてに、表題を [JN/Xalan] としてメールすること。
  • レビュー報告は原稿についてでも、プログラムについてでもかまわない。
  • 結城浩の著作権を尊重すること。

なお、レビュー報告のメールの情報は、 結城が連載や著作に利用させていただく場合があります。

…と上に書いて3時間のうちに2通のレビュー報告をいただく。 しかも重要な指摘ばかり…助かった…感謝!

[JN] UNIX USER連載『Practical Java Lesson』。 Xalanを使ってXSLTの練習。 原稿書きは続く。

[EP] C MAGAZINE連載「Enjoy Perl Programming」。 モジュールAlgorithm::Diffの紹介と利用例。 原稿書きは続く。

[DP] 『Java言語で学ぶデザインパターン入門』の 読み合わせは今週の金曜日。 精力的に仕事なさる編集の方から、 確認個所が多数あるので、 読み合わせの時間をたっぷりとってくださいという主旨のメールが来て嬉しくなる。 結城は読み合わせが大好きなのです♪

[JN] Xalanを使ってXSLTの練習。 ShowRSSを改造しようと思ったが、 そもそもXSLTの話やXMLの話を解説していたら長くなりそうなので、次回回し。 Javaも、XMLも、やたらと登場する長い名前をどう頭に収めるかが学ぶポイントの1つのように思う（そもそもプログラミング全般がそうかも）。 似て非なる名前がたくさん登場するからだ。 簡単な例を示す。 以下の4つはよく似ている長い名前ですが、どれがどういう意味合いのものか。

• javax.xml.transform.TransformerFactory
• javax.xml.transform.Transformer
• org.apache.xalan.processor.TransformerFactoryImpl
• org.apache.xalan.transformer.TransformerImpl

これは、Javaプログラマには以下のように見える。

• javax.xml.transform.TransformerFactory
• javax.xml.transform.Transformer

• org.apache.xalan.processor.TransformerFactoryImpl
• org.apache.xalan.transformer.TransformerImpl

つまり、前者2つはjava(x)で始まっているので、より標準的な、 よりベンダーに依存しないクラス（あるいはインタフェース）であろう。

次のように見ることもできる。順序を入れ替えて…。 Implがついているものは、ついていないものの実装（ベンダーが作成したクラス）だ。

• javax.xml.transform.TransformerFactory
• org.apache.xalan.processor.TransformerFactoryImpl

• javax.xml.transform.Transformer
• org.apache.xalan.transformer.TransformerImpl

また、オブジェクト指向な人（デザインパターンな人）には次のように見える。 Factoryがついている方が、ついていない方を生成するのだ。

• javax.xml.transform.TransformerFactory
• javax.xml.transform.Transformer

• org.apache.xalan.processor.TransformerFactoryImpl
• org.apache.xalan.transformer.TransformerImpl

という話は、Web日記にではなく、原稿に書かなければならないのだよ＞自分。

昨日の村上春樹の件、さっそく読者からご報告をいただきました。 うるうる…感謝します。 以下、引用。

  さて、5/6の日記で言及されていた村上春樹の小説の件ですが、

    「世界の終わりとハードボイルド・ワンダーランド」

の中のくだりで、

    「コーンのベースのダブルで、上がコーヒーラム、下がピスタチオ」

です（トリプルではなく、ダブルですね）。以下を当たって頂くとよいでしょ
う。

    新潮文庫 「世界の終わりとハードボイルド・ワンダーランド(上)」
    P130

※この小説、「ハードボイルド・ワンダーランド」と「世界の終わり」という
表裏一体となったストーリーが交互に出てくる構成になっているのですが、
現実世界である「ハードボイルド・ワンダーランド」の方は固有名詞のオン・
パレードになっていて、幻想的な「世界の終わり」との対比が上手いな、と
感銘した記憶があります。春樹ファン＆結城さんファンの私としては、結城さ
んのこの調査が何のためなのか非常に興味のあるところです。:-)

  では。

P.S.「Java言語で学ぶデザインパターン入門」に期待しています。

そうですか、ダブルでしたか…。 トリプルだったら、 まさにその『Java言語で学ぶデザインパターン入門』でちょっと使おうかと思っていたのです。 どこに？　それは出版時のお楽しみということで(^_^;。

ご連絡本当にありがとうございます。 応援のお言葉も、とてもうれしいです。

そういえば、『Java言語で学ぶデザインパターン入門』は目次を公開しました。 以下からご覧ください。

• 『Java言語で学ぶデザインパターン入門』

情報検索中、どなたかご存知ありませんか。

村上春樹のどこかの小説で、 主人公が女性にサーティワンアイスクリームのトリプル（だったかな？）を買ってきてあげるシーンがあるのですが、 そのときのフレーバー（と順序）を知りたいです。

（2001年5月7日に読者の方から連絡がありました。感謝します）

仕事の気分転換に、 メールマガジン『Perlクイズ』の≪若葉マーク≫を発行。 今回の問題は次のようなの。

• メールマガジン『Perlクイズ』

===========================================================
■今回のクイズ≪若葉マーク≫
-----------------------------------------------------------
●クイズ
-----------------------------------------------------------
とむらくん（仮名）は正規表現を勉強しています。

友人に、
「例えば、"me"で終わる英単語を探したいとするよねえ。
Perlだとこんな風に書けるんだよ」
と言いながら下記のスクリプトme.plを動かしました。

ところが実行結果を見た友人から、
「incomeやcameはいいけど、formeやJameって何だ？
それに、homeが抜けているよ」
と言われてしまいました。
以下の「期待する実行結果」になるように、
スクリプトを修正してください。

◆スクリプト(me.pl)
while (<>) {
    if (/[A-Za-z]+me/) {
        print "$&\n";
    }
}

◆テキストファイル(magi.txt)
The "Dillingham" had been flung to the breeze during a
former period of prosperity when its possessor was being
paid $30 per week. Now, when the income was shrunk to $20,
though, they were thinking seriously of contracting to a
modest and unassuming D.
But whenever Mr. James Dillingham
Young came home and reached his flat above he was called
"Jim" and greatly hugged by Mrs. James Dillingham Young,
already introduced to you as Della. Which is all very good.

◆実行の様子（コマンドライン）
perl me.pl magi.txt

◆実行結果（失敗）
forme
income
Jame
came
Jame

◆期待する実行結果
income
came
home

昨日の≪パズル≫もそうだけれど、 平日だろうが休日だろうがおかまいなしで、 読者からの解答メールの早いこと早いこと。 だいたい、発送から一、二時間でかなりのメールが来てしまう。

日記ダイジェストを更新。

• 1999-07-29 - ブラウン神父の秘密
• 1999-07-26 - シュタイナー教育
• 1999-07-24 - 出産
• 1999-07-12 - 月曜の賛美！
• 1999-07-08 - 中央線のために祈る / 満たされている喜び
• 1999-07-08 - プログラミングを身につけるには / 生きた信仰の第一歩
• 1999-07-05 - 月曜の思いから祈りへ
• 1999-07-02 - ほんとうに大事なものは、無償で、誰かから与えられるもの
• 1999-07-01 - 見えないものはいつまでも続く

メールマガジン『Perlクイズ』の≪パズル≫を発行。 今回の問題は次のようなの。 ひらめいた方は、ぜひ以下から参加して結城浩あてにメールでご解答ください。 掲示板には書かないでね。

• メールマガジン『Perlクイズ』

===========================================================
結城浩の『Perlクイズ』≪パズル≫ 2001-05-04 Puzzle.0016
http://www.hyuki.com/pq/
[PQ/P]≪パズル≫では実用性を無視したクイズを出します。
===========================================================
■今日の一言
-----------------------------------------------------------
こんにちは。結城浩です。

[PQ/P]≪パズル≫では実用性を無視して、
トリッキーな内容、謎のプログラムに挑戦します。
Perl初心者の方にはわけのわからないものも登場しますが、
適当に無視してくださいね。

メールマガジン『Perlクイズ』では3つの系統があります。

    [PQ]    標準的な「クイズ」
    [PQ/W]  初心者向けの≪若葉マーク≫
    [PQ/P]  実用性無視の≪パズル≫

読者のみなさんは自分に適した系統を選んでご解答ください。
解答はこのメールに「返信」してお送りください。
もちろんこれまでの[PQ]や[PQ/W]も続けて発行されています。

投稿者の名前は基本的には非公開です。
名前をアピールしたい方は「名前を公開してほしい」と
解答の中で主張してください。

今回の問題は、Perlのスクリプトとは思えないものが
Perlのスクリプトとして解釈されうるというお話です。
いまは連休中なので、解答は少ないかもしれませんね。
（最速解答は誰だろう…）

今回の購読者数は4133人です。
みなさんのご愛読を感謝します。
では、Enjoy Perl!
===========================================================
■今回のクイズ≪パズル≫
-----------------------------------------------------------
●クイズ
-----------------------------------------------------------
非常に小さな「アセンブリ言語」を理解するインタプリタを作ります。
レジスタはA, B, Cの3つ。演算子はmov,add,inc,outの4つ。
演算子の意味は次の通り(X,Yはレジスタ、Nは整数を表す）。
    mov X,N;    レジスタXに整数Nを代入
    mov X,Y;    レジスタXにレジスタYの値を代入
    out X;      レジスタXの値を表示
    add X,N;    レジスタXに整数Nを加算
    add X,Y;    レジスタXにレジスタYの値を加算
    inc X;      レジスタXの内容を1増加
以下に実行例を示します。

◆プログラム(asmtest.pl)
use strict;
use asm;

mov A,1;
out A;
mov B,2;
out B;
add A,B;
out A;
mov C,A;
inc C;
out C;
add A,2;
out A;

◆perl asmtest.plの実行結果
A=1
B=2
A=3
C=4
A=5

さて、ここで問題です。
asmtest.plが使っているモジュールasm.pmを書いてください。
===========================================================
結城浩の『Perlクイズ』
Copyright (C) 1999,2000,2001 by Hiroshi Yuki. <hyuki@hyuki.com>
http://www.hyuki.com/pq/
お送りくださる文章やプログラムは、
書籍や連載などで無断で利用させていただく場合があります。
===========================================================

EFF's Top 12 Ways to Protect Your Online Privacyがバージョンアップされているという情報を yomoyomoさんからいただいた。ありがたいことに差分まで送っていただく。 送っていただいて何だけれど、自分でも差分を作ってみようと思った。 既存のツールでもいいけれど、この間入手したAlgorithm::Diffが使えるのではないかと思い、 ちょっとプログラミングをしてみる。

# $fromと$toで指定した2つの英文のファイルの相違点を
# HTMLとして出力する。相違点は単語単位で出力。
# $fromからなくなった部分は赤文字で、$toで追加された部分は青文字で表示。

use Algorithm::Diff qw(traverse_sequences);

$from = 'eff_privacy_top_12.txt';
$to = 'eff_privacy_top_12_v16.txt';

open(FROM, $from) or die "$!";
open(TO, $to) or die "$!";

@from = split(/\s+/, join(' ', <FROM>));
@to = split(/\s+/, join(' ', <TO>));

print "<html>";
traverse_sequences(\@from, \@to,
    {
        MATCH => \&match,
        DISCARD_A => \&discard_a,
        DISCARD_B => \&discard_b,
    }
);
print "</html>";

sub match {
    my ($a, $b) = @_;
    print qq|$from[$a] |;
}

sub discard_a {
    my ($a, $b) = @_;
    print qq|<font color="red"><b>$from[$a]</b></font> |;
}

sub discard_b {
    my ($a, $b) = @_;
    print qq|<font color="blue"><b>$to[$b]</b></font> |;
}

これでできた。Perlは素晴らしい。

• YAMDAS Project (yomoyomoさん)
• あなたのオンライン・プライバシーを守る12の方法
• EFF's Top 12 Ways to Protect Your Online Privacy

[DP] 『Java言語で学ぶデザインパターン入門』の校正は続く。 今回は、いつもの本よりもざらざら感が少ない分、 内容の読み込みに時間を使うことができるような感じがする。 3回目の読み返しが18章まで進む。 GoFのデザインパターンの数と人間の染色体の組数が等しいのは偶然なのだろうな。

校正をしているうちに、 次の本（次の、次の本かな）のアイディアを思いついたのでいろいろメモ書きをする。

本を書く、というのはとてもチャレンジングでわくわくする仕事である。 新しい本を書く準備段階は、次のようなことを考える。 内容を考える。 読者について考える。どんな人が読むのかな。 その人たちはどんなことを知りたいと思っているのかな。 その人たちが困っていることは何だろう。 形式を考える。 説明の順序、例示の順序。 章立てとタイトルを考える。 各章の構成を考える。 …こういったことを順不同で頭の中でこねまわし、 紙の上にメモしていく。 この時点で考えたことが最後の段階まで残る場合もあるが、 たいていは修正につぐ修正の過程で影も形もなくなってしまう。 でも、考えることは無駄ではない。 説明の順序を考えながら、 実は題材をより深く学んでいることになるからだ。 自分が書こうとしている本が「どんな本なのか」を一言で言えるようになったら、 かなりその本についての理解が進んだといえるだろう。

[DP] 『Java言語で学ぶデザインパターン入門』はマーカ付けを一応完了。 もう少し深い読み込みをしてみようと思う。

[JN] UNIX USER連載『Practical Java Lesson』はXSLTである。 以前作ったShowRSSをもとに、Xalanを使ってRSS→XHTML変換をするブラウザを作ろうと思う。