| ホーム ＞ 結城浩の日記 ＞ 2001年11月 | 検索 | 更新情報 |
| 読者の声 | 先月 | 来月 | 日記ダイジェスト |
|
インターネットでWebページを巡っていると、 いわゆる中傷ページのようなものにときどき出会います。 内輪の愚痴こぼしというものでもなく、 建設的な批判ページというのでもなく、 不愉快な「悪口」を書きつらねているページです。 はじめのうちはその毒を興味深く読むのですけれど、 読んでいるうちに気分が暗くなったり、 いやな気持ちになってきたりすることがあります。 こういうページは, 読まないほうが健康によさそうですね。
もちろん世の中には批判すべき行為や、 非難すべき、警告を発するべき事象というのはたくさん存在します。 それに対してきちんとした 批判を行っているページを作ることは大事なことです。 でもここで書いているのはそういう建設的批判のページではなく、 また少人数のグループで「○○って○○だよねー」という、 なかよしおしゃべりのページでもなく、 何というのか…ええと、 「この人は何を考えてこんな悪口だらけのページを書くのだろう」 と思うようなページのことです。
Webページは各人の作品ですから、とやかく言うのも詮ないことですが。 そういうページはこちらの心をいつのまにか毒してしまうので、 注意して避けたほうがよいなあ、と私は思っています。
一般論になりますが、悪いものをけなすことに力を使うより、 良いものをほめることに力を使う方が健康かな、とも思うのです。 悪いものは無数にあるので、題材に困らないというのはあるかもしれません。 良いものは少ないので、見つけるのは大変です。 でもみんなが「これは悪い」というものを見つけてきて文句を言い合うよりも、 「これは良い」というものを見つけてきて紹介する方が有効な時間の使い方ではないかなあ、 と思うのです。 そういえば、イエスさまの「主の祈り」も、まずはじめに神さまに言及していますね。 悪魔に言及するのは後の方。
ええと、これで話が終わったらつまらないので、 私がよく訪れるページが持っている特徴のいくつかを書いてみます。 これはすべてではありませんし、この特徴をもっていないページが悪いページだというわけでは ありませんので念のため。
更新頻度が高いページ。 例えば、毎日訪れると、何かしら新しいことが書かれているページは、 定期的に訪れたくなります。
その人なりの独自な視点を持っているページ。 書いている人が、自分の考えで書いているページは、 興味深く読むことができます。 たとえその主張が自分の考えと違っていても。 また多少の毒や乱暴な言葉遣いをしていても。
そこにしかない情報があるページ。 自分に必要な情報が、世界中でそのページにしか存在しなければ、 そこに行くことになります。
豊富な情報を提供しているページ。 いろんなページのいろんな情報を集めて整理しているページは、 実質的に役に立つので、自然とそちらに足が向かいます。
心やすらぐページ。 そこのページにいくとほっとする、気分が楽になる、リラックスする、楽しい、 そんなページはうれしいものですね。 これは情報量や更新頻度とは無関係。 1つだけ例をあげると、稲本喜則さんの「ひぐらし日記」。 私はここの日記に何度も笑わせてもらいました。 言葉で遊ぶ面白い話は特に好きです。
多様な人が訪れるページ。 自分が普段出会わない人がやってきていろんな意見を書いているようなページは、 うーん、なるほど、ということが多いものです。
健全なページ。 私はクリスチャンなので、キリストに対する正統的で健全な信仰を表明しているページはほっとします。 それにときどきはっと身を正すような文章に出会えたりして。
みなさんは、きっと毎日のように訪れているページがあると思います。 そのページを訪れているのはどうしてでしょうね。
[EP] 引き続き[EP]のお仕事。プログラムはあれで一応形になったとして、 画面のキャプチャをやったり構成図をVisioで描いたり、リストを整理したり。 それから原稿のアウトラインを作り、表やメモ、謝辞などを書く。 関連URLを記入して、プログラムリストを埋め込み、 構成図をPDFとして出力する。原稿の分量を見てみると、 ここでだいたい50%といったところ。 たぶんあと正味4時間くらいで完成すると思うのだけれど、 集中力がここで尽きたのでストップ。あとは夕方か夜中に。
このメールがご不要なら、深くおわび申し上げます。 このメールはスパムではありません。 今後、このようなメールが不要な場合は表題にdeleteと書いてご返信いただければ、 そのメールアドレスへの送信を停止させていただきます。
…というようなメールが見覚えのないところから送られてきても、返信してはいけません。 返信すると、 「ほほう、このメールアドレスは生きていて、しかも人間が読んでいるのだなあ」と送信者にわかり、 「生きているメールアドレス」というリストに追加される可能性があります。 つまり、かえって迷惑メールを増やす結果になるかもしれません。 ご注意ください。
もちろん、 自分が以前サービスを要求したところからやってくるメールの場合には、 削除依頼を出してもよい場合があるでしょう。 そのあたりは自分の判断でよろしくどうぞ。
スパムメールには「このメールはスパムではありません」と書かれていることが多い。
[EP] というわけで夜中である。 だいぶ形になってきた。
YukiWikiMiniをベースに「テンプレートの切り換え」を実験中。 動的に切り替わるところまではいきませんが、 例えば以下のような感じになります。 以下の2つのWikiは同じ「モデル」を違う「ビュー」で見ています。
もう頭が回らなくなってきたので、このへんでお仕事はおしまい。 おやすみなちゃい。
最近、メールアドレスの最初がアンダースコア(_)ではじまっている不審なメールが 非常にたくさんくるのですが、これってウイルスかなにかでしょうか？ ご存知の方はいますか？
…以下のワームだそうです。川崎さん、情報感謝。
[EP] 今日は雑誌連載のお仕事。 shino＠freedomcatさんが以前言っていた「YukiWikiのUI部分を切り出す」という話からヒントをいただき、 HTML::Templateを使ってYukiWikiをカスタマイズする話を書こうと思う。 いろいろ実験するにはYukiWikiはいささか大きいので、 以前作っておいたYukiWikiMiniをベースに試してみることにしよう。
（ぱたぱた…）
うん、コマンドラインレベルでは一応動くようになった。 CGIとして動作させてみるのは今晩夜中にやることにしよう。 ヒントをくださったshino＠freedomcatさんには、 お礼のメールを出し、記事で触れさせていただくことにする。
先日書いた「技術系メーリングリストで質問するときのパターン・ランゲージ」は、 私の想像以上に反響をよんでいる。 私のところには感想・意見メールがぞくぞくとやってきて、 ちょっと驚いています。 そのうちの一部は以下でご紹介しています。 アドバイスもたくさんいただいているのですが、 全部反映させるのも大変なので、また機会をみてということで。
それから、(私の知っている範囲では)以下のページでもご紹介いただきました。感謝します。 あらためて、リンク。
質問
はじめまして。 「匿名メールとリメーラ」みさせていただきました。 とてもわかりやすい説明ですばらしいと思います。 私も早速自分宛てに送ったのですがいまいちうまくいかず、リメーラから またかえってくるみたいなんです。 返ってきたメールを翻訳しても全然意味がわかりませんし。 よろしければ間違いをご指摘いただけないでしょうか。 メールは、 Returned mail: Host unknown (Name server: remail.obscura.com.:host not found) です。
回答
エラーメッセージをみると、指定したホストが存在していないようです。 あの「匿名メールとリメーラ」のページはずいぶん古いので、 紹介されているリメーラのサイトの中にはもう存在しないものが多数あると思います。
[DP/2] 今日も今日とてマルチスレッド（すみません、毎日似たような仕事ばかりで）。 12個目のサンプルの説明の文章を書き、お話のパターンのクラス図をVisioで描く。 すごく、すごくいい。心にしっくりくるよい図ができた。 そう、これが私の言いたかったことなんです、という図になった。 パターンの最後の章なので、説明の文章も復習の意味合いを持たせ、回顧的な含みを持たせるようにする。 ほら、ここに出てきたのはあそこで学んだパターンですよね。 ほら、あっちに見えているのはあのパターン、 それからこれは、もうおなじみのあれですね。 ね、簡単なパターンでも、 きちんとやっておくと、大きなプログラムを理解するときに とても助けになるでしょう？ …とまあそういうお話の展開。 今月中に12個目のお話を送付するのは難しそうだな。 まあぼちぼち行きましょう。
プログラムっていろんなことを「語っている」なあ。 プログラムを書くときにいろんなことを考えて、配慮して書きますよね。 それを日本語で解説していくと、すごく勉強になる。 きちんと説明しようとすると、説明がどうしてもごちゃごちゃするところがある。 それは、実は、プログラムがごちゃごちゃしているからなのだ。 説明文を書くと、論理展開や、他の部分との関連をはっきりさせる必要が生じ、 プログラミングしているときに「何となく」感じていたことを、 明記する必要が生じる。 これはプログラムの構成を整えたり、バグを見つけたりするのに非常に有効だ。 ソースレビューがプログラムの品質を高めることもこれに関連しているように思う。
プログラミングを学んでいる人（特に学生さん）に強くお勧めするのは、 自分が書いたプログラムや自分が書いた文章をWebで公開することだ。 自分が書いたプログラムを公開し、その説明文を書いて公開する。 プログラムそのものでなくても、プログラミングにまつわる技術情報、ツールの使い方などを 説明文として書き、HTMLなどで整形し、Webで公開する。広く公開する。 これはすごく勉強になる、と私は確信しています。
おうおうにして 「私はまだうまくプログラムを書けないから」 「たいしたプログラムじゃないから」 「きたないプログラムなのでお見せするほどではない」 「公開するのは恥ずかしい」 「もう少し勉強が進んでから」 …そういう風に考えがちだけれど、 私はそうは思わない。
「私たちはみな工房の徒弟であって、だれも巨匠になれはしない」というのはヘミングウェイの言葉だったかな。 勉強している途中であるからこそ、うまく書けないからこそ、公開するべきだと思うのだ。 恥ずかしかったらペンネームでも使えばいい。 それから「いま勉強中」とでも書いておけばいい。 無料のWebサイトだってたくさんあるからたいしたお金はかからない。 とにかく自分が学んだことを「他の人に見せる」という意識をもって構成してみることが大事だ。 うまくいかなかったらやめればいいじゃないか。
自分ひとりで作って、ひとりで楽しんで…というのも結構なことだけれど、 思い切って公開すると、きっと思わぬ世界が広がります。 もちろん、世の中には心無い人がたくさんいます。 いわれのない悪口のメールがやってくることもあるでしょう。 あなたの意気込みを「引き下げ」熱意に「水を差す」メールも来るかもしれません (意外と悪口メールは来ないものですけれど)。 けれど、そんなメールは恐れないで。読み流しましょう。 あなたは、自分のペースで学んでいるのですから、他の人と比較する必要なんてありません。 自分がマスターしたい技術、マスターしたい言語を淡々と学んでいきましょう。
自分がよくわかっていないのに「わかったふりをする」のが一番よくない態度です。 よく知らないのに「ああ、それはもう知っているさ」という態度、これがいちばんよくない。 それは技術を学ぶ態度ではなく、他の人の目を気にしている態度だ。 なんでもかんでもわかったふりをしないこと。 そうではなく、 自分はここまでわかった、あれはまだよくわかっていない、これは得意だ、あれは不得意だ… 自分の現状をそのようにきちんと把握しましょう。 自分が理解したことがあるなら、その分だけ公開してみること。 他の人からのフィードバックは謙虚に聞き、参考にする。 いやみや悪口などは聞き流す（でもその中に事実が書かれていたらその部分だけは謙虚に受け止める）。
謙虚に学びましょう。素直に学びましょう。失敗したら戻ってやり直しましょう。 自分の知っていることを、知らない人に丁寧に教えてあげましょう。 教えてあげることも1つの勉強であると思いましょう。 自分の知らないことを教えてくれる人に感謝しましょう。 誰かの気分を害することがあったら、すぐに謝罪しましょう。 けれどもくよくよ悩むのはやめましょう。 Web, 書籍, 雑誌, メールなどで情報収集しましょう。 でも情報収集することを本来の目的とはきちがえないようにしましょう。 いつも自分の頭と心で判断しましょう。
プログラミングというのはとても魅力的で刺激的な技術です。 自分だけで知識を抱え込み、ちまちま学ぶのではなく、 もっと広い心をもって、学んだことを公開し、知識や知恵を他人と分かち合い、 互いに励ましあって歩みましょう。 そうすると、学ぶことがもっと楽しく、 もっと豊かに、もっと広がりを持ってくるように思うのです。
Webが流行し始めた頃「個人からの情報発信」ということがよく言われましたね。 何か「ものすごい」ことを考え出して、人が「あっと驚く」ようなページを作るのが情報発信ではありません。 あなたが毎日やっていること、学んでいる1つ1つのこと、 それらに自分なりの形を与えて公開するのが「あなたにとっての情報発信」なのです。
あなたのご活躍をお祈りしています。 あなたのページができたら、ぜひ掲示板に書き込んで教えてくださいね。
そうそう「よかった探しリース」にもご参加くださいね。 この機会にホームページデビュー！
「技術系メーリングリストで質問するときのパターン・ランゲージ」のページは、 多くの方から賛同をいただけたようで、とてもうれしいです。 特に、JavaHouse MLに情報を流してくださった、OZAWA -Crouton- Sakuroさんに感謝します。 JavaHouse ML経由で訪問いただいた方からは、多数の感想やフィードバック、意見などを受け取っています。
以下、感謝のリンク。
[DP/2] 今日も今日とてマルチスレッド。12個目のお話の続きを書く。 プログラムの説明文を少し書いたけれど疲れたので一休み。
長男のピアノの腕前は急上昇している。 練習が終わった後、私と家内が拍手をして「うまいねえ！」というと、 ちょっぴり照れくさそうな顔をしてソファに体当たりする。 その後、デジモンで遊ぶ。
次男は、毎日ひたすらよく食べている。 寝冷えしないように、どてらと寝袋のあいのこのようなものを着て眠るのだが、 朝起きると、だだっと私の部屋にやってきて「自分で脱げるんだよ、ほら」という主旨の アピールをする。脱げると「ね、脱げたでしょ」とこちらを向いてにっこりする。 次男をひざにのせて「関心空間」を見ていると、 ロゴのスキンヘッドのおじさんが気になるらしい。 アニメGIFのおじさんがにやっと笑うと、 次男は「おじちゃん、にっこりー」と言う。
次男はハーボットもお気に入り。 私のひざの上で「はーぼっと、みゆー」と宣言する。 何か食べて笑うハーボットを見て「にっこりっ」と言う。
「技術系メーリングリストで質問するときのパターン・ランゲージ」なるものを書いてみました。 技術系メーリングリストというよりもプログラミング系メーリングリストですけれど。 メーリングリスト(ML)というのは現在たくさん存在しています。 情報交換や質問・回答などの場として貴重な存在です。 メーリングリストはメールでやりとりしますから、 メールのエチケットはそのまま通用するのですが、 メーリングリストならでは、というエチケットも存在します。 それについて気がついたところから書いております。 ご意見・ご要望など大歓迎ですので、よろしくどうぞ。
きちんとした質問を書く努力をすると、 質問を書いている段階で問題解決することが多々ありそうですね。
先日のLNCセミナーで「いま技術系メーリングリストのパターン言語を書いています」とおしゃべりしたところ、 そこにいらしたある方から「それを読んでくれる人っていうのは、あまり困ったメールを出さないんですよね」という コメントをいただいた。 うーん、確かにそうかもしれないですね。 「メールのエチケット」といったページを読んで欲しい人ほど読まない。 読む必要がない人はきちんと読んでくれるという矛盾。 もっとも、他の人を指導する立場の人の時間を無駄に使わないという可能性はありますね。 いちいち自分で説明しなくても「例えばこのページ読んでおきなさいね」と言うだけで済むので。
質問
はじめまして 日記の「私の開発環境」を読みました。 秀丸を使っておられるとのことですが、 DTPについてはどうなさっておられますでしょうか?
私も秀丸を使ってますが、 DTPにはもっぱらLatex2eを使っております。 論文・書籍ともに専用のスタイルファイルを用いております。 秀丸のマクロを使わないそうですが、 秀丸のLatex用マクロは大変重宝しております。 学生時代はMule上でYatexを使っておりましたが、 今は秀丸上で全てを処理しております。
回答
結城はDTP(desktop publishing)をほとんどやりません。 しいていえばLaTeXですね。 LaTeXを生で書くことはなく、 MakeWebというツールからLaTeXのソースを吐かせ、 Adobe Distillerを使ってPDFにしています。 同時にHTMLも作っています。 以下に「マッチ売りの少女」の例を挙げます。
本を作るときも、原稿はプレーンテキストで入稿します。 一度だけLaTeXで入稿したことがあります。 でも、手間がかかりすぎるのでもうやめました。 LaTeXで書くと、ついレイアウトの方に意識がいってしまい、 肝心の本文の日本語を読み込むという部分が不足がちになるので、 おそらくもうLaTeXで入稿することはないと思います。
体調はあまりよくない。 お医者さんに見てもらったら「風邪」とのこと。 咳のクスリをもらったが、これは非常によかった。 水分を取るときには、あたたかい飲み物で取るように、体を冷やさないように、とのこと。 家内によると、カレーは体を冷やすらしい。 南国で食べるものは体を冷やし、北国で食べるものは体を温める。 地面から離れて高いところにできるものは体を冷やし(果物など)、 地中にもぐるものは体を温める(にんじん、大根など)、とのこと。 ふむー、なるほど。
[DP/2] 今週もまた『Java言語で学ぶデザインパターン入門』マルチスレッド編の続きである。 いまは12個目のお話を書いている。今日はサンプルプログラムのクラス図を描く。 まあまあよし。 11月30日ごろまでにはレビューアさんたちに送付できるだろう。たぶん。
『Java言語で学ぶデザインパターン入門』マルチスレッド編の全体像は見えてきたので、 もうすぐ細部をつめていく段階に入る。 12章まで書いたら、まとめの章を書く。 それから、もう一度最初から読み直す。 そのときに、 レビューアさんたちからいただいたフィードバックを反映させていく。 クリスマスまでにそこまで行きたいものである。 年内ぎりぎりに脱稿かなあ。
[DP] そういえば、 『Java言語で学ぶデザインパターン入門』の読書会が開かれています。 月一回のペースで、全部で5回〜6回になるとのことです。 先日第一回目(〜4章まで)が行われました。 まわりもちで「朗読」していく形式のようで、 事前の予習は特にいらない模様。 みなさんお忙しいので、あらたまって勉強の時間というのはとりにくいものです。 この読書会では、その場でみんなで勉強しましょう、というスタンスのようです。 結城は参加していませんが、よろしければ以下をごらんになって、ご参加ください。
Javaのパターンや、 Perlのプログラミングに関して個別に質問メールをいただくのですが、 できればメーリングリストに投げていただいた方がよいかと思います。 私以外の人から適切な（私よりも適切な）回答をもらえる場合もありますし、 他の人の参考にもなりますので。 もちろん、私個人にメールしては困る、というわけではありませんが、 仕事の都合により返事が出せない場合も(多々)ありますから…。
恒例の「よかった探しリース」を今年も開催します。 もう参加できますので、どうぞ！
この企画、1997年から毎年開催しています。今年で5回目！
私は『Java言語プログラミングレッスン』に以下のような「対話」を書きました。
生徒 「プログラムはセンスで書くんですか。インスピレーションで書くんですか。」 先生 「プログラムはプログラミング言語で書くんですよ」
これは詩人（たぶんマラルメ？）が言ったという逸話のパロディです。
誰か 「詩はインスピレーションで書くんですか」 詩人 「詩は言葉で書きます」
私があの「会話」を『Java言語プログラミングレッスン』で書いたのは プログラムをこれから学ぼうという人にセンスだのインスピレーションだのと 言っても何の役にも立たないと思ったからです。 センスだのインスピレーションだのという前にやるべきこと、 できることはたくさんあると思うのです。
もともと、プログラムの世界でみんながやろうとしていることの1つは、 「天才のひらめきがなくてもよいプログラムを作るにはどうするか」ということです。 コンパイラなんかはそのいい例ですね。 それなのに「プログラムを書くにはセンスが必要」と言ってもねえ、 と思うのです （センスやインスピレーションが不要だと言いたいわけではありませんが）。
私が好きなのは、 『Perl言語プログラミングレッスン』入門編の はじめに書いた以下のような文章です。 少し長くなりますが引用します。
* * *
Perl言語は、 TMTOWTDI（ティムトゥディ）というモットーを持っています。 TMTOWTDIというのは、
There's more than one way to do it.
の略語です。 その意味は「方法はたった一つではない」「もっと別のやり方もある」ということです。 同じ動作をするプログラムであっても、 問題を解決する方法はたった一つの「正解」があるわけではなく、 人によって千差万別なのです。
言いかえれば、初心者は初心者なりにPerlでプログラムを書いていい。 ぎこちなかったり、無駄が多かったりするかもしれないけれど、 それはそれでいいんです。 Perlのすべてを完全に理解してから珠玉のプログラムを書くのではなく、 自分の現在の実力に応じたプログラムを、いま、書くのです。 ちょうど、それは人間が言葉を話すのと似ています。 まだ語彙も少なく言葉をうまくあやつれない子どもでも、 「あのね、あのね、おやつ、ほしいの」などと子どもなりに表現する。 多少まわりくどかったり、もっとエレガントな表現があるのかもしれないけれど、 大事なのは「おやつがほしい」という気持ちが相手に伝わることなんです。 Perlの一文字目 'P' が Practical （実用的な）であることを思い出してくださいね。
プログラミング言語は「言語」なのだから、 人によっていろんな表現があっていいと思います。 多様で自由な表現ができ、しかも実用性が高いPerl言語を通して、 いっしょにプログラミングを楽しんでいきたいものですね。
この文章をお読みのあなたへ。
あなたはいま誰かを「指導」していますか。自分の子供を、生徒を、後輩を、部下を…。 教えたり、導いたり、助けたりしていますでしょうか。 もしそうなら、ぜひその相手を「励まして」あげてください。 気をくじいたり、やる気をそぐような言葉ではなく、 次の一歩を進めたくなるような、新たな挑戦をしたくなるような、 そんな一言をかけてあげてください。 少々ぎこちなくてもいいんです。くどくど言う必要もないんです。 ただ「よくやったね」「よくできたね」「ここがいいなあ」「なるほどね」「うん、なかなかいいね」 「じゃあもう一回やってみようか」「それはすごい」…そういったちょっとした一言をかけるだけでも、 雰囲気はがらっと変わるものなのです。
もちろん、例えば相手の状況や性格などによっては励ましが悪影響を与える場合がありますから、 その点には十分ご注意ください。
(以下は、C MAGAZINE 2001年11月号向けに書いた原稿です)
私が普段使っている「開発環境」は次のようなものです。
すべてのプログラム、すべてのドキュメントは秀丸エディタを使って書きます。 秀丸エディタは自分が使いやすいようにキーアサインなどを調整しています。 でもマクロまでは書きません。 複雑な処理をさせたい場合には、 別途Perlでスクリプトを書くようにしています。
Javaの開発環境はJava Development Kit (JDK)を「素」で使っています。 Integrated Development Enviroment(IDE)のような Graphicalな統合環境は使っていません。 また、jdbなどのデバッガも使っていません。 ほとんどのバグはソースと実行結果を見比べることでとっています (これは普段それほど巨大なプログラムを構築していないからかもしれません)。
Perlも同じように、Perlインタプリタを「素」で使っています。 perl -dを使うことはほとんどありません。
プログラミングに関する文章（連載原稿や書籍）を書いているときには、 大量のサンプルプログラムを書きます。 そのときには、 原稿ファイルの中にプログラムをまとめて書いてしまいます。 そして実行テストを行うときにはPerlで書いた自作のスクリプトで 原稿ファイルの中からプログラムを抽出＆実行します。 これによって、原稿ファイル中のプログラムが確実に動作することを保証します。
自作のスクリプトは単純なものですが、 単純なだけに何をやっているかを100%把握でき、 また新たな機能が必要になった場合には手軽に追加することができます。 そういう意味で私にとっての開発環境のカスタマイズとは、 自作のスクリプトを書き換えることを意味します。
プログラミングしやすい開発環境というのは ストレスを感じず作業に集中でき、 自動化できるものを極力自動化したものだと思います。 IDEは自動化しにくいので、Perlスクリプトを主に使うことになります。
プログラミングから少し離れますが、 毎日の作業として欠かせないのがWebページのメンテナンスです。 そのときに使っているのもPerlの自作スクリプトです。 私はHTMLを作成するのにMakeWebというスクリプトを使い、 それをサーバに送信するのにUpFtpというスクリプトを使っています。 これらのスクリプトをmakeと組み合わせて使えば、 ストレスが少なく自動化された開発環境が構築できます。
質問
こんにちは。 ちょっとした質問です。 私は、30行以上ある文章を画面で読むと、目が痛くなってしまいます。 さらっと流し読みする分には大丈夫なんですけれど。 結城さんはよくネット上の文章を読んでおられるようですが、 目は疲れないのでしょうか？ 何かこつとかアドバイスがありましたら教えていただけるととても助かります。
回答
こんにちは。メールありがとうございます。 そうですね。ほとんど一日中コンピュータの画面で文章を読んでいますねえ。 目はとても疲れます。肩も凝るし…。 やっぱり連続して読まないのがよいみたいです。 ときどき休んで体を動かすのですね。 あまりアドバイスにはなりませんでした。 ごめんなさい。
[DP/2] いよいよ12個目のお話。まずはサンプルプログラムをパタパタと書いていく。 動かしながら説明の文章を考え、章の構成をにらみつつプログラムを修正していく。 十分にシンプルに作りながら、トリビアルだと感じさせないようにするにはどうしたらよいか。 …それがわかれば苦労はないのですけれど。まあ地道にいくか。
『ひと月百冊読み、三百枚書く私の方法』をまた読み返している。 この本には、文章を書く仕事をしている人に役に立つヒントがたくさん詰まっています。 本を読んで気になったページの端を折っておけ。 文章が書けなくなったらフォームを守れ。 自分が「いい文章」だと思うものを分解して真似るための方法。 実際、福田和也さんのこの本自体がとても読みやすい。 文章の話とか仕事の話っておうおうにして個人の趣味に走ったり、 妙に衒学的になったり、自慢話に終始したりしがちなのだが、 この本は平易な言葉で、自分の経験に根ざした具体的な方法を分かりやすく記述している。 「いい仕事」をしたい人にお勧めの本ですね。
なお、 この本はずいぶん以前の森山さんの日記で知りました。 森山さんに感謝します。
体調不良である。
Pattern Almanac 200のLindaさんに「お会いできてよかった」というメールを出したところ、 「あなたの本は、きっとプログラマの役に立つ本になると思いますよ」という嬉しいお返事をいただく。 ああ、またここにも「励まし」がある。励まされるってうれしいものですね。
セミナーでお会いした方からもメールを多数いただいて感謝します。 特に、オージス総研の山内さん（オブジェクトの広場）は、 会場で結城が尋ねたUMLの件をわざわざ調べてメールしてくださいました。 恐縮です。
[DP/2] というわけで11個目のお話にやすりをかけて、おおよそ形になる。 図版の調整をして読み直しをし、再度動作テストを行ってから、 レビューアへの送付準備を行う。 ふう。やっと11個目まで来た。 今月中に12個目を送付できるだろうか。
質問
結城さん、いつもためになる日記をありがとうございます。 質問があってメールしました。
結城さんはオブジェクト指向をどうやって勉強しましたか。 オブジェクト指向を身に付けるにはどうしたらいいんでしょう。 どんな本を読めばいいですか。
回答
結城は、オブジェクト指向プログラミングを、 C++とSmalltalk-80の本を読んで勉強したように記憶しています。 学生時代でした。 そのとき「オブジェクト指向というのは『オブジェクトが偉い』という方法論」 だということは知っていましたけれど、 実際に「ふんふん、そういうことか」と分かったのは、 Bjarne StroustrupによるC++の本を読んで、 自分でプログラムを書いてからだと思います。 メンバ変数とメンバ関数を定義してクラスを作り、 インスタンスを作り…そういう体験を通して、 次第次第に、自分の中にオブジェクト指向のキーワードが 具体的なイメージを伴なうようになっていったと思います。
オブジェクト指向の用語って小難しいじゃないですか。 クラス、インスタンス、インヘリタンス、ポリモルフィズムなどなど。 それに惑わされず、プログラムを通して理解することは大事だと思います。
以下は半分余談です。
はっきり言えるのは「これを読みさえすればすぐ身につく」という参考書はない、 ということです。参考書はいつもきっかけに過ぎません。 自転車乗りや水泳と同じで、 必ず「自分で考え、自分でやってみる」というプロセスが必要です。 あなたが 「オブジェクト指向を学ぶための魔法の本がどこかにあって、 それを手に入れて読みさえすれば、オブジェクト指向が身につく」 と万一（心のどこかで）思っているなら、 それは誤っています。 それなりに時間と期間をかけて、自分の頭と手を動かして、 1つ1つ地道に学んでいくのが結局は早道なのです。 よい参考書はそれをほんの少し手助けするに過ぎません。
応援していますね！
[DP/2] とめておいた11個目のお話に戻って書き進める。 だいぶ形はできてきた。 あとはもう少しヤスリをかけなければならない。 つまり、書くべき内容と順序をどうするかはもう書いたけれど、 そこで使われている用語や表現は不適切な状態、ということ。 うまく12個目のお話にもつながりそうだし、よかったよかった。 感謝感謝。
お返事しなければならないメールを多数いただいているのですが、 返事できていません。ごめんなさい！ プログラムに関する質問に個別にお答えすることも困難です。ごめんなさい。 Perlの質問はperl-lesson MLの方に送っていただいた方が回答は早いと思います。
仕事を何もしない、静かな日。
「関心空間」というサイトはすごく面白い。 キーワードを自由に登録し、互いにつなげたりコメントをつけたりする。 Wikiより制限は大きいが、その代わりに構造がすぐに生まれていく。 とりあえず「パターン」というキーワードをいれてみました。
Jim CoplienにThank youのメールを出したところ、お返事がやってきました。 Copeは、MensorePLoPや一昨日・昨日のセミナーで、 みんながhelpfulでinformativeでengagedであったことを喜んでいらっしゃいました。 また、結城の本についても励ましとアドバイスを書いてくださいました。 感謝、感謝。
そういえば、先日Doug Lea先生からいただいたメールでも感じたんですけれど、 エライ先生って、みんな「励ますのがうまい」と思います。 励ますのがうまいし、具体的で、的確なアドバイスをする。 しかも短い文章の中で。 やっぱり、人に何かを教える立場の人は、こうでなくっちゃ。 うんうん。私も常に人を励ますように心がけよう！
パターンに関わっているいろんな人の話を聞いたり読んだりしていると、 そこには「自分にできるところから、まずはやってみよう」というスタンスが感じられます。 例えば、Doug LeaのPattern FAQの中でも、
問「なぜ○○に関するパターンが書かれてないのか？」
答「あなたが書いていないから」
というのがある(#24)。
あなたは何かに関心がある。 関心があって、何か少し（ほんの少しでも）それについて学んだとする。 学んだことは本当に少しかもしれないけれど、 その分だけ、何かを人に伝えることができる。 まずは、何かを書いてみよう。まずは、何かをやってみよう。 それはすべてを網羅してはいないかもしれない、 完全ではないかもしれない、誤りを含んでいるかもしれない。 でも、きっとそれには意味がある。 それを土台として、どこかの誰かが何かを悟るかもしれない。 何かをはじめるきっかけになるかもしれない。 もっとよりよく理解する１ステップになるかもしれないのだ。 だから、まずは、現在の自分にできることからはじめてみよう。 ささやかながらも形にしてみよう。そしてそれを思い切って他の人に見せてみよう。 多くの人に公開してみよう。フィードバックを受け取る機会を作ってみよう。 そうすれば、きっと何かが起こるから。
今日は、Jim Coplien, Linda, Neilが講師のInArcadiaのパターンセミナーに参加しました。 MensorePLoPには参加できなかったのですが、 著書を通してお世話になっている有名な方々に1度お会いしようと思って出かけて行きました。 場所はお台場(テレコムセンター)のタイム24というビルです。 天気もよくてゆりかもめからの眺めはとてもきれいでした。 ゆりかもめの駅の名前には適当なでこぼこがあって、 記憶しやすいなあと思いながら。
Copeの講演は、Symmetry Breakingのお話でした。 (以下は要約ではなく、結城の心に残った部分のメモです) 自然界には真の(global)symmetryはなくて、 (global)symmetryがbreakして、 local symmetryへとredistributeしている。 global symmetryしか持たないpureなもの(言語)だけで 記述しようとすると(かえって)無理が生じる。 生き残るプログラミング言語というのは、 そうじゃないのじゃないか？ ヘテロなものの方が残っているじゃないか。 aspect-orientedな方法論は、 symmetryを導入することによって、symmetry breakingを取り扱おうとしているが、 これは擬似的な方法であり無理がある。 (繰り返しますが、これはいいかげんなメモです。適当に読んでください)
コーヒーブレークのときに、 Lindaさんに、 あなたの編集なさったPattern Almanac 2000を読みましたよと話しかけたところ、 Lindaさんは「あら！あれを《読んだ》の？それはすごいわねえ！」とにっこり笑う。 あわわ。もちろん年鑑を全部《読んだ》わけではないですう…と笑いながら言い訳。 結城が、だいたい一人で仕事をしていて、 メールなどで他の人とコミュニケートしています、 という話をする。 Lindaさんが「あら！私もそうよ。一人でミーティングして、お家でお仕事。 そして他の人とメールのやりとり。ときどき他の人とテレビ会議ね」とうなずく。
[DP/ML]の参加者のお一人と、 レビューアのお一人と一緒に、 楽しくおしゃべりしながらお昼を食べる。 その後、 「[DP/ML]に参加しています…ROMですけれど」という方々から名刺をいただく。 ありがとうございます。 FAQの翻訳を[DP/ML]でやったときにサポートしてくださった上手さんからも名刺をいただく。 恐縮です。 みなさんから、 デザパタ本読みましたよ、 会社でも何人も持っていますよ、 例の「猫」は面白いですね、 「絵本のパターン」は奥さんに見せたらうなずいていましたよ、 などと言っていただけてとてもうれしかったです。 ありがとうございます。 結城も、いま書いているマルチスレッド編の予告編をほんのちょっぴりおしゃべり。
午後はCopeのセッションの続きと、パネルディスカッション。 結城は、パターンを書くときに「読者」をどう考えるか、 という質問をする。 これは前から気になっていたこと。 あるパターンと、そのパターンのパターン記述は別物であって、 読者層に合わせたパターン記述があってしかるべきではないか、と思っている。 Copeからは「そうはいっても『まず一人の読者に理解してもらう』ところから スタートするのだろう」というコメントをもらう。 そしてPattern Writer's Workshopの形式について示唆を受ける。
その中で、Workshopの中ではPattern Authorはただ聞くだけである、 というスタンスは面白く、しかも正しいと思った。 それは何かというと、パターン記述については著者の補足説明を口頭で行うというのは 「なし」であって、「書かれたものがすべて」であるということだ。 その上で、 「参加者が著者の書いたものをどう読むか」という様子を 著者が聞くというのはとてもよい。 それは、非常に多次元的で意味深いフィードバックだと思う。 うん。これはよくわかる。 いまマルチスレッド編を書いていて、レビューアから受けるメールがそれと近い。 読者同士の「議論」はないけれど、読者（レビューア）がどう感じるかを 生のままフィードバックしてもらうというのはライティングにとって非常に重要だ。 特にレビューア層と読者層が一致している場合は。 Pattern Writer's Workshopがうまく機能するのは、 参加者の層と、そのパターンの読者層が一致しているからだろう、と思う。
Lindaからは、確かにエキスパートが書いた短いパターン記述を普通の人が理解できない、 ということはよく生じる。そのためにパターンのフォームをどう選ぶか、どう改良するかということも大事。 はじめに短いパターン記述があって、エキスパートならそこだけ読めば理解できる。 経験がない人ほど先まで読んでいけば、より詳しく理解できる。そういう形式がいいですね…という話を聞けた。
考えてみれば、結城のデザパタ本も、パターン記述の1つの形式になっていることになる。 章のタイトル→章のイラスト→日常生活の例→パターン名の意味の解説→サンプルプログラム→パターン解説 →考えを広げるためのヒント→関連パターン→補講→練習問題…という流れは、 結城が「読者に最も分かりやすいだろう」と思って書いている順序になる。 そのときに思っていることだけれど、 「パターンを記述しよう」というよりも 「読者にパターンを理解してもらおう」という意識の方が強いように思う。 パターンをできるだけ正確に、Completeに伝えることよりも、 まずざっくりと、どういうことをお話したいのか、というイメージを伝えようとしている。 そのために、可能な限り具体的→抽象的という順序を守っている。 パターンよりもプログラムの方が具体的。プログラムよりも日常生活の例の方が具体的。 だから、日常生活の例→プログラム→パターン、の順序で書いているのだ。
パネルディスカッションの後、 Copeに『Java言語で学ぶデザインパターン入門』をプレゼントとして渡す。 「サインして」というので急いでサインする。 サインといえば、 (株)豆蔵の白川さんのカウボーイハット(?)にもサインさせていただく。 あのカウボーイハット、 MensorePLoP2001の参加者のサインで埋まっていましたね(^_^)。
などなど。 いろんな方からいろんなお話を聞けてとても嬉しかったです。 1つ1つここに書ききれません。ごめんなさい。 でも、本当に楽しい一日でした。 みなさん、ありがとうございます。
(ハイになって書いている文章なので、以下は流し読みしてください)
[DP/2] というわけで、午後の仕事。 11個目のお話はまだとめておき、12個目のお話の続きを書く。 コードスケッチは破綻なく終わったが、 もっとよい例を思いついたのでプログラムは明日書き直すことにしよう。 それよりも図だ。 いま、UMLのクラス図を描いていて、顔がほころびるくらいうれしい。 なんて美しい図だ。 うん、やっぱり変奏曲の方がシンプルで本質的な解説がしやすい。 特に、本書を読んできた読者にとってはこっちの方がよい。 そうしよう。 それにしても、美しい図だ。
うん、実例は嘘をつかない(実例では嘘をつけない)けれど、 図も嘘をつかないな。 もちろん、機械的にプログラムをクラス図に置き換えることはできる。 でも、何かを主張するためにクラス図を描くのは、 かなり技術を要する仕事だと思う。
例えば、それはこういうことだ。 Proxyなどのdelegationが登場したときには、 クラス同士を「いかにも委譲しています」という感じに横に並べたい。 それから、自然な流れとして左から右にクラス図を「読める」ようにしておきたい。 そう、クラス図は構造を表現したものだから時間順序なんてないのだけれど、 人間はそんなことにはおかまいなしに左から右に図を「読んでいく」。 だから、典型的なシナリオに読者が乗れるようにクラス図も構成するのがよいだろう。 これはUMLのアートワーク技法ですね。
そうか！「UMLで描くためのパターンランゲージ」というのも作れるわけですね （というわきみちにそれていると、本の完成が遠のくのでやらないけれど）。
話がそれた。 さっきまで、12個目のお話で、 メソッドのinvocationとexecutionの分離をいかに 効果的にクラス図でアピールするかに腐心していました。 それが、ぴぴっとひらめいて（聖霊に感謝）、 うまくおさまったので、とても舞い上がっているのです。 本書の前の章でとりあげてきたパターンのいくつかが、 最終章のパターンの中におさまって、 きゅっと引き締まった感じになりました。 とても大きなカタルシス。 前著で、Abstract Factoryパターンや、 Bridgeパターンが理解でき、クラス図にぴたりと収まったときの感じと似ている。 ああっ、美しい。 本を書くって、なんて素晴らしいお仕事なのでしょう。
さて、これからの作業は、 いったんいま捕まえたものを忘れたつもりにならなければなりません。 それは、いまからこの章を読む読者の立場になるということです。 読者の帽子をかぶるのです。 そして「いま（読者の帽子をかぶっている）私は、 何を知っているだろうか。何を次に知りたいと思うだろうか」 と考えるのです。そして急いで著者の帽子をかぶって、 読者に伝えるのに一番抵抗のないもの、一番自然なものから書いていくのです。 それは、ちょうど、愛する人の手をとってエスコートするようなものです。
「それでは、あそこまで一緒に行きましょう。足元に気をつけてくださいね」
[DP/2] 11個目のお話は完成直前でとめておき、 少し12個目のお話のスケッチをする。 Schmidt先生の元論文にできるだけ添ってサンプルを作ろうとするが、 とても不自然な例になってしまったので破棄する。 というか、これまで何回作っても不自然な例になったので、方針変更。 午後になったら、 元論文に書かれている変奏曲の方を元にサンプルを作ってみることにしよう。
自分が理解したかどうかを確かめるいい方法の1つは、 「例」を作ってみることだ。 そしてその「例」を使って他の人に説明を試みることだ。 きちんと説明できたら自分は理解している。 きちんと説明できなかったら自分は理解していない。 シンプルな試金石。
実際に動くプログラムを作るというのは、 ソースコードという具体例を使って、 コンピュータという相手に自分の理解した内容を説明しているようなものだ。 きちんと動作したら自分は理解しているし、 きちんと動作しなかったら自分は理解していないことになる。
例は嘘をつかないのだ。
[DP/2] まだ11個目のお話を書いている。 でも、だいぶまとまってきた。 おそらくあと4〜5時間で決着がつくであろう。
読者からの質問
パソコンの仕事がしたい！との一言ですが、 できましたら専門職につきたいとの一心です。 前からプログラミングが気になっておりましたのでチャレンジしたいのですが、 どこから始めればよいのでしょうか？ (33歳 会社員 女性)
回答
現在あなたが何ができて何ができないのか、 将来あなたが何をしたいのかがよくわからないので なんとも答えることはできませんが…。
「パソコンの仕事」といってもたくさんあります。 「専門職」といってもさまざまです。 本当に無数にあります。 書店に売っている就職情報誌などで、 どういう職種があり、それぞれの職種に必要な能力や知識などを調査するのがよいと思います。 インターネットを使えば、さまざまな職種の方々の意見もオンラインで読めるかもしれません。
長期計画で専門的な職種をねらうのか、 それとも手っ取り早く何かパソコン関連の仕事をしたいのかによっても 方法は変わると思います。
まずは、 自分がイメージしている「仕事」を（ある程度）はっきりさせましょう。 そして、自分が現在持っている能力・知識・経験と、 その仕事に必要とされる能力・知識・経験を（ある程度）はっきりさせましょう。 その上で、学校に通うなり、独学するなり、いきなり仕事をはじめるなり、 次の一歩が決まると思います。
まずは「状況の把握と整理」からはじめましょう。
God bless you!
体調がいま1つよくない。
高校2年生の読者から、とてもうれしいメールが届く。 こういうメールをもらえるというのは、 とても幸せなものですね。 ありがとうございます。
(前略) 結城さんが現在執筆中のJavaのデザインパターンのマルチスレッド編ですが、 大変楽しみにしています。 Javaの魅力に心を奪われた全国の結城さんファンのためにも執筆作業 がんばってくださいね。 P.S. 結城さんの日本語はきれいですね。 とても憧れています。
[JN][EP] 連載原稿を送付。 編集部のみなさま、いつも遅くて申し訳ありません。
体調がいま1つよくない。
現在、沖縄でパターンのカンファレンスMensorePLoP 2001が開催されています。 鷲崎さんの「ほげ日記」でリアルタイムにその様子がうかがえます。 とても楽しそう…(^_^)
[DP/ML] 結城が管理者をしている「デザインパターン・メーリングリスト」は、 デザインパターン、Java言語、オブジェクト指向、UMLやeXtreme Programming関連のおしゃべりや情報交換の場になっています。 現在の参加者は1800名以上、もう少しで2000名になろうとしています。 一日のメール流量はそんなに多くありませんし、 ROM大歓迎・自己紹介不要(してもよいですが)なので、 みなさんどうぞお気軽にご参加ください。 過去ログは参加者でなくても閲覧することができますので、 雰囲気をつかむことができます。
質問
突然ですが質問です。 結城さんはこれほど大きな個人サイトをどのようにして効率よく管理しているのでしょうか。 11/9の日記を見る限りではあたかも、いままで自分が書いた文章がどこにあるか忘れないように、 全て何処にあるか覚えているように感じます。
ディレクトリの管理等のルールに何かしら工夫をしているのでしょうか。 また、この日記はcgiなど使うことによって更新しやすくしているのでしょうか。
僕自身も最近自分のサイトを管理するようになったので、 そういったことが気になります。 もし、おひまがあれば教えていただきたい。
ではでは。
回答
HTML作成には、MakeWebという自作のツールを使っています。 手でHTMLを書くことはあまりありません。
定期的に更新するファイルをサーバに更新するときには、 UpFtpという自作のツール(というほどでもないが…)を使っています。
コーナーごとにディレクトリを分けてはいますが、 3階層以上深くはなっていないと思います。
2001年11月9日の日記のように、 以前書いた文章に対して言及をするときには、 秀丸エディタのgrepという機能を使って指定ディレクトリ以下のファイルを全検索します。 Google.comを使ってサイト内検索をする、という方法もあります。
質問
結城さんは、連載記事も書いているし、 本も書いていらっしゃいます。 新しいことを学ぶときは、いったいどうやっているのでしょうか。
回答
結城は「人に教える」ことを通して学んでいるように思います。
[JQ][PQ] メールマガジン発行サイトの「まぐまぐ」から、 最近メールマガジン発行していませんね、というお知らせをいただく。 親切なことに「もし、ご多忙等でしばらく発行できない事情がおありでしたら、 近況報告かたがた、読者の皆様にお知らせしていただければ幸いです」 というアドバイスまで書いてくれている。 確かに正しいアドバイスなので、従うことにする。
[EP] Perlのモジュール紹介。今月はWebのロボットの予定。
[DP/2] 引き続き11個目のお話を書いている。 もう「ガーン、破棄」はなさそうである（たぶん）。 レビューアさんからも続々とメールをいただく。 うれしい、うれしい。 レビューアとのメールのやりとりは現在約1082通。 みなさん、ありがとうございます。
[DP/2] 引き続き、11個目のお話を書いている。
どうも破棄が多すぎるのでおかしいと思い、 もう一度いろいろと調べ物。 どうやら、私の理解にずれがあった模様。 でも、私の理解の方がシンプルでわかりやすいのではないかと思い、 注意書きをつけて先に進むことにする。
ここまで何回も何回も何回も何回も書き直してきたから、 舞台に登場する役者も台本もすべて頭に入っている。 その状態で参考書や参考論文を読むと、すごく理解が早い。 参考書が言わんとしていることも理解できるし、 例も理解できるし、それに、本の誤植もすぐに見つかる。 Webページのerrataを確認したら確かに間違っていた。
人の間違いを見つけてふふふ、と思っていたら、 私が以前Webページに書いていた内容の間違いも見つけた(^_^;。 えてしてそういうものです。 謙虚な気持ちを忘れてはいけません ＞ 自分。
ええと、間違っていた（というか例としては不適切だった）部分は、 パターン紹介のThread-Specific Storageパターンの部分です。 errnoだけではなくLegacySystemImplのインスタンスをすっぽりThreadLocalに入れれば、 synchronizedは不要になるのです。
レビューアとのメールのやりとりは現在約1069通。 みなさん、ありがとうございます。 1つ1つのメールが貴重な宝石のようです。
[DP/2] というわけで、11個目の話のリトライである。 今日のお仕事も、昨日のお仕事をすべて破棄するところから始まった。 しかも、念のいったことに、午前中にやり直したお仕事も、 やっぱりまずいことが午後にわかって全部破棄。 ぐすん (;_;) 。
でもその後は何とか持ち直して、 プログラムと図まではたどり着いた。感謝、感謝 (^_^)V 解説文を書いていくうちにまた「ガーン」とならなければいいのだが。 …でも、まずいことが分かるなら分かった方がいいのだけれど。
ところで、この結城のサイトwww.hyuki.comでは、 アマゾンのアフィリエイトをやっていますが、 最近本の注文が定期的にあって感謝です。 平均すると一日一冊くらい売れているようです。 買ってくださっている方 (もちろん私には誰が買っているかはまったく分かりませんが)、 ありがとうございます。
SPAMメールの話。 結城のメールボックスには毎日何通もSPAMが来ます。 ふと思いついてSPAMの「読ませようとする努力」を少し分類してみました。
最後の「間違いメールを装う」というのは、 「間違っていますよ」という返信メールによって、 生きているメールアドレスを収集しようとする高度な手口の可能性がある。 人の親切心を逆手に取った手法。
[DP/2] 今日も今日とてマルチスレッド。 11個目のお話を書いている。 今日のお仕事も、 下ごしらえで準備していたプログラムの間違い(不適切な部分)を見つけて、 全部破棄するところから始まった。 やれやれ。 でもプログラムを破棄する代わりに、 「こういう風にしてはいけない」という項目が1つ追加された。 よしよし。
それにしても「パターン」の考え方はとても素敵だ。 「名前をつけて統治する」(Name and Conquer)というのがいかに強力であるかがよくわかる。 今日書いているパターンを整理していると、自然にProxyパターンが登場してきたし、 も少し改良するならここでFactory Methodパターンを使えばよいとわかるし。 ファクトリを作るのが面倒ならClass Side Factoryですませばよい。
GoFが23個のパターンを作って広めてくれたおかげで、 その用語をベースにして意思疎通ができる。 当たり前のことであっても 軽視せず、よく考えて、整理して、まとめるというのは、 本当に大事なことなのですね。
… 一日仕事してきて、 最後に、プログラムのよくない点が見つかって、 今日の仕事は再度ぜぇんぶ破棄。 とほほほほ。
でも、感謝。 また明日トライしようっと。
[DP/2] 10個目のお話がまとまってきた。 今晩か、明朝にはレビューアの方々に送れるだろう。
予定しているお話は12個。あと2個ですね。 その後にまとめの章を設けようと思っている (まとめの章を設けるというアイディアはレビューアさんからいただいたものです。感謝！)。 それから、付録も書かなくてはいけないから、 完成・脱稿まではまだまだですが。 おっと、それに、 レビューアのみなさんから寄せられた意見を本文にフィードバックしなくては。 書き加えるだけではなく、書きすぎた部分を削る作業も必要だし。
レビューアさんとのやりとりのメールは現在1000通ほど。 レビューアさんからは、いつもあたたかい励ましと、 鋭く的確な指摘をたくさんいただいています。 本当に感謝します。
レビューの形式は特に決めておらず、 レビューアさんの好きな形式で書いていただいております。 技術的な内容とは別に「感想」もたくさんいただき、 それもまた結城の執筆に直接的・間接的に役立っています。 ありがとうございます。
レビューアさんからいただいた感想の中から、 (レビューアさんのプライバシーを守りつつ) いくつかご紹介いたします。
午前中は礼拝。お昼からデパートで買い物。夕方から仕事。
[DP/2] 10個目のお話を書いている。 ああ、もう、この章のサンプルプログラムは何回書き直したことでしょう。 プログラムを書く。動かす。プログラムをじっと眺める。解説文を書く。 解説とそぐわなかったり、主張したい要点とずれていたりする。破棄。 もう一度プログラムを書く。動かす。プログラムをじっと眺める。 解説文を書く。書いているうちに、またおかしな部分が見つかる。破棄。 もう一度プログラムを書く。動かす。プログラムをじっと眺める。 解説文を書く。けっこううまく書ける。 図を描いてみる。描いているうちに、おかしな部分が見つかる。 ガーン。破棄。
もうちょっと目端が利かないものかと、自分でがっかりする。 さっき記録を調べてみたところ、 10章書いてくる間に本半分くらいの量のテキストを破棄していますもの。 (というのは具体的には300KBくらいのテキストということです。 『Java言語で学ぶデザインパターン入門』のテキストは約600KB)
なんて私は不器用なのだろう。 でも、そうやって何度も何度も書き直しているうちに得られるものもある。 書きたい内容が心にしっくりと理解できるようになってくるし、 同じようなトラブルをきっと読者もするであろうと想像がつくようになるし、 ええと、それに…タイピングも速くなるし…(^_^;
実際、タイピングの速度は重要です。 タッチタイプができる人は共感していただけると思うが、 文章をタイプしているときっていうのは、 キーを打っているという意識はあまりなくなる。 キーを打っているというよりも、文章を書いているという意識になる。 自分が口で話すのに近い。心の中でお話をする。 それを手に伝える。すると手がキーボードの上で踊ってくれて、 その文章をタイプしていく。「自分」は画面に登場する文章を読んでいる。 心の中でお話をした文章が画面に登場するのを読んでいる、 という感覚でタイプしている（ですから、 あなたがもし、キーボードを見ながらキーを打っているなら、 ぜひタッチタイプを学んでください。ぜんぜん世界が変わりますから。 強く強くお勧めします）。
Javaのマルチスレッドの本を書いていて、山ほどサンプルプログラムを書いているうちに、 「InterruptedException」とか「synchronized」という長い単語も一気に（しかも高速に）タイプできるようになってしまった。 それどころか「new Thread() { public void run() { ... } }.start();」とか、 「new Thread(new Runnable() { public void run() { ... } }).start();」だって大丈夫。
やれやれ。
何の話だっけ。まあいいや。
休憩終わり。仕事に戻ります。
[DP/2] 9個目のお話を書いている。だいぶまとまってきたので、 おそらく今日の夜か明日の朝にはレビューアの方々に送信できるだろう。 面白い発見がたくさんあって、とても楽しい。 自分で理解していると思っていることでも、 実際に文章として書き表してみると、 いかに自分の理解が不十分であるかがわかって嬉しくなる。 感謝、感謝。
[DP/2] 9個目のお話をまだ書いている。何となく形になってきたが、ちょっと疲れたので、 10個目のお話のイラストを描いたり、お話のあらすじをもう一度振り返ってみたり。 …って書いていると「物語の本」みたいだけれど、実際は「マルチスレッドの本」です。 それから今回の本で紹介するパターン相互の関係図を少し修正したり。
上の絵は、 結城が描いた、おもちゃで遊んでいる「スレッドおばけ坊や」です。 他にもいろんな「スレッドおばけ」たちが本書には登場します。
下の絵は、 おもちゃを片付けている「スレッドおばけ坊や」です。
…やっぱり「物語の本」みたいだな。
レビューアのみなさんとのメールのやりとりは、 現在919通になりました。感謝します。 もうすぐ1000通になるなあ…。
まず、言い訳から書く。 本来、この文章は一ヶ月前に書かれるべきものだった。 一ヶ月ほど前から、私は——たぶん神さまからだと思うんだけれど——この文章を書くようにうながされていた。 何度も何度もこのテーマを思い出させられ、 文章の順序、構成を考えさせられてきた。 文章をエディタで入力する前から、私は文章の全貌がどうなるかわかっていた。 でも、さまざまな都合により、入力する時間がとれず、 ついつい先延ばしになってきたのだ。 きっと誰か——私の知らない誰か——に向けてこの文章は書かれているのだと思う。 この文章は皮肉について書かれていて、 例によって、もっともらしくて優等生風の文章です。 けれども私は、この文章を特定の人に向けて書いているわけではない。 この文章を読んで「結城さんは私にあてこすりをしているのだ」と思わないでください。 私はこの文章をただ書いている。 というか、書かされているのであって、 誰を題材にしているわけでもない。 あなたがもし、以下の文章を読んで不愉快に感じたらごめんなさい。 あなたがもし、あなたのそばの皮肉屋さんのことを思い出したら、 その人のために祈ってください。 以上、長い言い訳、おしまい。
皮肉について
皮肉を言う人がいる。 年に1回ではなく、1日に1、2回は必ず皮肉を言う人がいる。 その人はきっと、もともと賢い人だ。 皮肉というのは二重の意味を持った表現だ。 賢くなければ皮肉は言えない。 複雑な表現を操る技術が必要だからだ。
でも、皮肉を言ってばかりいるのは、そのせっかくの「賢さ」を 曲がった目的のために使っている。 それはとてもよくない。
「二重の意味」について説明する。 「うまいですね」と相手をほめるとしよう。 文章そのものは、相手をほめている。 しかし、この文を声に出すときの微妙なイントネーションや間合いによって、 これを皮肉にすることができる。 言葉では「うまいですね」と言っているのに、 相手はまったくほめられた感じがせず、 むしろ「へただなあ」と言われたかのように感じさせることができる。 それが二重の意味。2つの意味（ほめること、けなすこと）を 1つの言葉に乗せているのだ。
皮肉は人間同士のコミュニケーションを深いところから蝕む。 皮肉屋は、皮肉を繰り返す。 さまざまな場面は変われども、言う相手は変われども、 皮肉屋は、何度も皮肉を言う。 あるときはけっこうきつい印象をあたえ、あるときはちょっとしたからかいのムードで。 何度も何度も皮肉を言う。 皮肉な言葉を積み重ね、二重の意味を持つ言葉を操る。
皮肉に反論するのは難しい。 「そんなこと言わないでください」と文句を言うと、 「え、わたしはあなたのことを『うまいですね』とほめているんですよ」とうそぶく。 皮肉屋は、二重の意味の片方を取り上げて、するりと身をかわす。 皮肉屋は、その芸当に快感を感じると共に、二重の意味の中に逃げ場を作っている。 皮肉屋は、弱くて孤独だ。 賢いけれど、弱くて、孤独で…毎日皮肉を言っている皮肉屋。
巧みに表現を操って、自分の賢さを示そうとする皮肉屋もいれば、 そんな意図はまったくなく、単に習慣になっている皮肉屋もいる。 どちらの場合でも、よろしくない。 皮肉屋本人にとって、よろしくない。
ある日、ある時。 いつもはひょうひょうとしている皮肉屋も、寂しさを感じることがある。 あるいはまた、しみじみとした思いを抱いて他の人と素直な言葉をかわしたくなる。 切実な思いをもって、何かを訴えたくなるときがある。
しかし、そのとき。 それまで積み重ねてきた皮肉な言葉が、皮肉屋を裏切る。 皮肉屋が、真面目に自分の真情を語っても、他の人はそれを割り引いて聞くだろう。 心から人をほめたいと思ってそう言っても、他の人はほめられたとは感じないだろう。 他の人は、皮肉屋の言葉から、裏の意味を読み取ろうとするだろう。 だって、これまでもずっとそういう言葉を聞かされてきたから。 長年積み重ねてきた皮肉な言葉、 二重の意味を持つ言い回しの積み重ねが生んだ悲しい状況。
だから、皮肉をやめよう。 皮肉を言うのをやめよう。 悪意を持って言うのはもちろんのこと、 からかいまじりにしゃべる癖を何とかして改めよう。
意識し始めてからやめるまでには、 きっと想像以上に長い時間がかかるだろう。 それだけ皮肉はあなたを蝕んでいたのだ。 皮肉があなたの舌にはりついていたのだ。
皮肉を使って他の人に賢さを証明する必要なんかない。 あなたが賢いことは、誰にだってすぐわかる。 自己の存在を誇示する必要なんかない。 あなたは、かけがえのない存在だから。 他人をからかってささやかな優位を保つ必要なんかない。 あなたは、素晴らしい存在なのだから。
あなたの「賢さ」を、 もっと意味のあるところに使おう。
もし二重の意味の表現を操るアクロバットを楽しみたいのなら、 「正しい知識」と「励まし」を同時に相手に伝えるような方向に努力をしよう。 少ない言葉だけでも相手を本当の意味で喜ばせ、励まし、力づけ、なぐさめる。 そんな言葉を生み出せるように知恵を使おう。 （もしクリスチャンなら、神さまにそのことを祈ろう）
あなたが「皮肉の罠」から逃れ出ることを祈っています。