＞
結城浩の日記 ＞
2005年1月
|
＞
結城浩の日記 ＞
2005年1月
| 検索 |
| プロフィール | 日記一覧 | 日記ダイジェスト | Twitter | RSS |
|
結城が持っていたGmail Invitationsの権利4個分は、 連絡くださった方に先着順でお送りしました。 ご応募・応援メッセージをありがとうございました。 間に合わなかった方、ごめんなさい…。
結城の手元にGmail Invitationsが4個あります。
feedbackからご連絡くだされば、どなたでも希望なさる方に差し上げます。
完全先着順。
必須な情報は、あなたの (1) First Name, (2) Last Name, (3) Email です。
できましたら、いきなり「希望」と書くだけではなく、あなたがどんな方であるか、
それから結城のページのどんなところを読んでいらっしゃるかなどを多少書いてください。
今日は都内で打ち合わせがあり、時間に余裕があったので、 新宿の紀伊国屋書店に寄りました。 3階のコンピュータ書のところで、 自分の本を見つけては手を触れ「この本を、必要な読者に届けてください」とお祈りしていました。
ふと気がつくと、出版社の関係者らしい人が2人いるのを発見。 そっと柱のかげに隠れて見ていると（比喩）、 その2人は書店の人と相談をしたり、本の在庫数チェックをしたり、 最近の売れ筋商品について熱心に話し合ったりしています。 手に取っている本から見ると、どうもソフトバンクの方らしい。
なおもじっと見ていると、 視線を感じたのか「結城先生ですよね」と先方から私に声を掛けてきました。 やっぱりソフトバンクの方でした。 結城の新刊の売り方についてちょっと相談をしてから、 私はお仕事の邪魔にならないように別れました。
一冊一冊の本について、 あんなに熱心に・丁寧にケアしておられるのだなあ、 と感動したひとときでした。いつもありがとうございます。
遅ればせながらやっと『境界線』を購入して読み始めました。 見た目はけっこう厚くてびっくりしたのですが、 読み始めてみると、すごく面白いですね、これ。 まだ一章しか読んでいないのですが、何だか身につまされることがたくさんでてきて、 考えさせられます。
冒頭はシェリーという働いている主婦の話。 シェリーは勤勉で真面目。彼女は、誠実に愛にあふれた人間関係を築こうとして涙ぐましいほどの努力をしている。 母親との関係、子供との関係、夫との関係、職場の同僚や上司との関係…、 そのすべてについてシェリーはがんばっている。 でも、シェリーが期待するほど彼女の人生はうまく回っていない。
その原因は何か？
シェリーは怠け者ではない。もっと努力すれば解決するという問題ではない。 愛や奉仕の精神が足りないわけではない。シェリーは十分に他の人に尽くそうとしている。 でも、その奉仕の割には、周りの人は喜ばない。 周りの人はシェリーの奉仕に対して、まるで何も受け取っていないようだ。
いったい、なぜだろう？
原因は「境界線」にあるのではないか、とこの本の著者は述べます。 自分に責任のある範囲 ——境界線—— をはっきりと定めること、 それができていないと、いろんなことがめちゃくちゃになっていく…。
C#で試しにプログラムを書いてみたいとき、 .NET Framework SDK を使うと手軽。
JDKをダウンロードして、javacでコンパイルするのと似た感覚。.NET Framework SDKをダウンロードして、cscでコンパイルする。
結城の日記をダウンロードして、ファイルoutput.htmlに保存するC#のプログラム。
using System;
using System.IO;
using System.Net;
namespace NetSample {
public class MainApp {
static String URL = "https://www.hyuki.com/diary/";
static String FILENAME = "output.html";
public static void Main(String[] args) {
Console.WriteLine("URL = {0}", URL);
Console.WriteLine("FILENAME = {0}", FILENAME);
WebRequest request = WebRequest.Create(new Uri(URL));
WebResponse response = request.GetResponse();
using (Stream inStream = response.GetResponseStream()) {
using (Stream outStream = new FileStream(FILENAME, FileMode.Create)) {
while (true) {
int c = inStream.ReadByte();
if (c == -1) {
break;
}
outStream.WriteByte((byte)c);
}
}
}
}
}
}
何となくC#で遊ぶ。
using System;
namespace Collatz {
struct Range {
public int min;
public int max;
public int walks;
public override String ToString() {
return "[" + min + ".." + max + "] (" + walks + ")";
}
}
public class MainApp {
public static void Main(String[] args) {
int maxwalks = 0;
for (int i = 2; i < 10000; i++) {
Range r = Collatz(i);
if (r.walks > maxwalks) {
Console.WriteLine("{0} : {1}", i, r);
maxwalks = r.walks;
}
}
}
static Range Collatz(int n) {
Range r;
r.min = n;
r.max = n;
r.walks = 0;
while (n != 1) {
if (n % 2 == 0) {
n = n / 2;
} else {
n = n * 3 + 1;
}
r.walks++;
if (n < r.min) {
r.min = n;
}
if (r.max < n) {
r.max = n;
}
}
return r;
}
}
}
csc Collatz.csでコンパイル。
Collatz.exeを動かす。
2 : [1..2] (1) 3 : [1..16] (7) 6 : [1..16] (8) 7 : [1..52] (16) 9 : [1..52] (19) 18 : [1..52] (20) 25 : [1..88] (23) 27 : [1..9232] (111) 54 : [1..9232] (112) 73 : [1..9232] (115) 97 : [1..9232] (118) 129 : [1..9232] (121) 171 : [1..9232] (124) 231 : [1..9232] (127) 313 : [1..9232] (130) 327 : [1..9232] (143) 649 : [1..9232] (144) 703 : [1..250504] (170) 871 : [1..190996] (178) 1161 : [1..190996] (181) 2223 : [1..250504] (182) 2463 : [1..250504] (208) 2919 : [1..250504] (216) 3711 : [1..481624] (237) 6171 : [1..975400] (261)
Range.minはあまり意味がなかった。
27はすごいな。
久しぶりにHaskellの本をちょっと読む。
何となく森博嗣も。
Paul Grahamの「知っておきたかったこと」という文章を改めて読む。 これは読む価値のある良い文章だと思いますね。 すべてに賛成するわけではありませんが、 いろいろと考えるきっかけを与えてくれる文章だと思います。 翻訳してくださったShiroさんに感謝します。
で、私自身の話。 高校時代に「知っておきたかったこと」って何だろう。 と考えてみたのですが、実はあまり思い浮かばない。 これを知っていたら、あのときのあのような失敗はしなかっただろうに、 ということはもちろんたくさんあります。 でも、今からあの時代に戻り、その失敗を回避したほうがより幸せになっただろうか、 と自分に問うてみると、そう簡単に結論は出ないように思うのです。
逆に「知っておいてよかったな」と思うこともたくさんあります。 でも今度はその「知っておいてよかった」ということを「もっと早く知っていたら、より幸せだったか？」と考えてみます。 それはやっぱり違う。 物事を知るにはやはりタイミングというものがある。 音楽と同じで、適切なタイミングで適切な音を出すから音楽が成り立つ。 早ければよいというものではないように思う。
（書いていて、あったりまえのような気がしてきました。でも続けますね）
もし、私が「高校時代の自分」に何か語るとしたら、どんなことを言うだろう。
そんな感じかなあ…。
以下、思いつくままに。
信仰というもの —— 「信仰」という表現に抵抗があるなら「人生観」でもよいけれど —— は、想像以上に重要な意味を持つ。
人生観とは何か。
何が良いことであり、何が悪いことであるか。 人生というものをどのように考えているか。 自分はどのような道を歩いて行きたいと思っていて、いまそれができているかどうか。 何が本当に大切なことであるか。 自分はどういう存在であり、いまここに生きている意味は何か。 … 大雑把にいって、それが人生観というものでしょう。
四六時中そんなことを考えて生活はできないけれど、 人生の要所要所では、上のような問いに何かしらの答えを出さなければならない局面が出てきます。
たとえば、 自分の進路を考えるとき。 就職先を考えるとき。 結婚について、子供について、住まいについて考えるとき…。
そんなとき、自分なりの「答え」を出さなければならないことがあります。 眉間にしわを寄せて生真面目な答えを出さなければならないわけではないし、 自分を客観視するユーモアの感覚がないと悲惨ですけれどね。
結婚について考えるときは、特にそう。 お付き合いしている相手といろいろと話をする。 そのときって、正面切って「あなたは人生をどのように考えていますか」と聞くことは少ないかもしれないけれど、 真剣に結婚を考える相手には、結果的にはそれを問いたくなるんじゃないだろうか。 だって、結婚をするというのは人生の大半を一緒に過ごす、同じ道を並んで歩く、ということですよね。 だとしたら、相手が人生というものをどのように考えているか、 （そしてもちろん、相手が自分をどのようにとらえているのか）ということを知りたいと 思うものではないのだろうか。そうでもないのかな。 そういうベイシックな問いっていうのは、顔かたちやスタイルよりもずっと大切じゃないかと思うのです。
結城の書いた
オレオレ証明書クイズ（問題編） /
（解答編）に対して、
高木さんからコメントをいただきました。ありがとうございます（高木さんは結城の描いたギコ猫も読んでくださったようですね (^_^) ）。
さて、高木さんの主張の要点はこうです。
はい、高木さんの主張は基本的に正しいです。
その上で、わたしの考えを少し書きます。
そもそも、私が「オレオレ証明書クイズ」を書こうと思ったきっかけは、 高木さんが書いた「警告を出す証明書をめぐる担当者とのやりとり」を読んだからです。 たとえば 「小学生にセキュリティ警告を無視させる埼玉県」の記事ですね。 この記事は苦笑せずには読むことができないものでした。 苦笑しつつも、私は気になることがありました。 それは、読んだ人の多くも苦笑しているだろうけれど「何が悪いのか」を理解していないまま苦笑している人も多いだろうなあ、 ということでした。
そして、高木さんの書いた記事を私なりに「短く」まとめたい、という気持ちになりました。 クイズ形式にすると、読んでいる人も「実は自分はわかっていないのかも」あるいは「結構この問題って微妙で複雑なのだな」ということを 理解するのではないかな、と思いました。 それであのクイズを作ってみたわけです。 ただ、解答提示後のフォローアップが不足だったかもしれません。
証明書に関する警告が出ました。 そこで出ている警告は、ブラウザが持っている証明書からパスをたどることができないという意味でした。 それはSSLが持っている「暗号化＋認証」のうちの「認証」の部分を無効にするものです。 でも「暗号化」そのものはなされています。受動的な傍受者は盗聴できません。 ただし、相手が認証されていない状態での暗号化は、 「単純な偽サイトによる攻撃」や、 「man-in-the-middleによる能動的な攻撃」を可能にしてしまいます。 ですから、SSL利用者が期待していることは達成できません。
私は「（証明書で警告が出ても）暗号化は正常」という表現は、 「技術的には正しい」けれど「利用者の期待からすると誤り」だと思っています。
「技術的には正しい」というのは「相手との通信は確かに暗号化されているから」です。
「利用者の期待からすると誤り」というのは「正しい相手との通信は暗号化されているとは限らないから」です。
稲本さんが本を出版なさったので、ご紹介します。 内容は、稲本さんの日記が元になっているらしいです。
稲本さんの日記は、肩の力を抜いて読める楽しい文章が多いので愛読しています。 特に「コトバをちょっといじるだけで全く違う世界が開ける」という題材は、 私のお気に入りです。 たとえば、 「文章を酔っぱらわせる」とかね。 いま読みながら笑っちゃった。
RSSを使った検索サイトの中には、(1)「BlogのRSS配信を対象として検索する」だけではなく、 (2)「特定のキーワードを検索した結果をRSSで配信する」という機能を持つものがある。
あ、えーと、(1)と(2)の違いはわかりますよね。 (1)の場合には、RSSは検索の対象になっている。いわば、RSSは入力。 (2)の場合には、RSSは検索結果を出すために使われる。いわば、RSSは出力。
一回しか検索しないという単語もあるけれど、 継続してウォッチし続けたいという単語も多い。 もともと「ある単語を検索する」というのはその単語に関心を抱いているわけだしね。 そんなとき、(2)のように検索結果をRSSで配信しているサービスはありがたい。 BloglinesのようなRSSアグリゲータを使えば、 その単語に対する複数サイトの検索結果を、 ずっと「RSSでウォッチし続ける」ことができるからだ。
たとえば、結城の場合には、 私のサイトに言及してくれている人を追うために「結城浩」と「hyuki」という単語をウォッチしている。 それから「Java」「Perl」「暗号」なども。
具体的にいうと、 宮川さんのbulkfeeds.netや、なおやさんのfeedback、それに、いしなおさんのblogmapなどには、 検索結果をRSSで出力する機能がある。 livedoorやgoo, exciteなどにも。
その一方で、(1)の機能は持っているのに(2)の機能がないサイトもある。 たとえば、ココログ。 それから意外にもはてなダイアリー （はてなキーワード、JAN/EANのウォッチはできるけれど、日記のウォッチはできない）。
追記
読者さんから「MSNも」という情報をいただきました。
最近思うのだけれど、 読者の方からフィードバックをよくもらう記事（日記のエントリ）というのには、 いくつかの特徴があるようだ。 当たり前のものもあるが、意外なものもある。
たとえば、先日の 「円周率が3だったら…」という話題は、 「家族の話題」かつ「短い記事」という特徴を備えていて、 結城あてにたくさんのコメントをいただきました（お返事できず、すみません）。
それから、Knuth先生の『The Art of Computer Programming』に関する 記事はたった一行でしたが、 梅田望夫さんのBlogで取り上げていただき、 多くの方からreferしていただきました。
「突っ込みどころがある記事」の例を自分で示すのは忍びないので、 具体的には示しませんけれど、 たいてい「眠い」か「ほろ酔い気分」で書いたエントリですね。 思うところをつらつらと書いただけのエントリに対して、 ていねいな、長いフィードバックをいただいたりすると、 申し訳ないような、ありがたいような気分になります。
結城のところには毎日たくさんのメールや（フィードバック送信フォームによる）フィードバックが 届きます。もちろんすべてをありがたく読んでいますが、 個別にお返事することはなかなかできません。ごめんなさいね。 これまで何回も書いていますけれど、 あまり不快なメールってやってこないものですね。 みなさんご存知のように、結城は自分の思想・信条をはっきりWebページで書いていますし、 けっこう生意気なことを書いていると思うのですが、 いわゆる…何ていうんでしょうか…「いやがらせメール」の類は、ほとんどこないように思います。
結城が日記などで表明している意見に批判的な（異を唱えるような）メールの場合でも、 多くの方が、ほんとうにていねいで、配慮に満ちた文章を送ってくださるのです。 そういう文章、みなさんからのフィードバックを読んでいると、 何とも、ありがたいなあと思うのです。
いつも、結城のつたない日記を読んでくださってありがとうございます。 これからも、いろんなことを書き散らすと思いますけれど、 どうぞ、よろしくお願いしますね。
オレオレ証明書クイズ（問題編）と その解答編に関してお便りをいただきました。
読者さんから
暗号通信の前提として、通信の秘匿性が保証されてなければならないと思いますが、 そのためには相手が秘密鍵(公開鍵の復号鍵)をちゃんと秘密にしているということが 仮定できていなければなりません。 もし、秘密鍵を第三者が持っているようなおそれがある場合は、 正常な暗号化とは言えないと思います。 どこの馬の骨かわからない輩をわざわざ選んで「こいつを信用してもいいよ」とか 言わせている人が秘密鍵をちゃんと秘密にしてくれるのでしょうか?
ということで、 解答は(1)は「秘密鍵の秘匿性に問題があるので正常とは言えない」 (2)「秘密鍵を第三者が持っている可能性があるので通信の秘匿性が保たれてない可能性がある」 とシンプルに答えれば良いと思います。
結城から
はい、その主張は正しいと思います。
その一方で、実は正しい証明書が送られてきたときも、 同じことが（可能性は低いですが）いえると思います。 技術力のない善人よりも技術力のある悪人のほうが、 鍵管理についてはしっかりしている、ということは十分にありえます。
つまり、 SSLのサーバ管理者が秘密鍵を正しく管理しているかどうかは、 証明書を見ただけではわからない、ということです。 問題としては「暗号化」「認証」「鍵管理」を分けて問うたほうが適切だったかもしれませんね。
ちなみに、PGPの鍵管理では「信用できる鍵かどうか」 と「相手が鍵管理者として信頼できるかどうか」を区別しています(拙著『暗号技術入門』(p.337)参照)
今後とも気がついたことがありましたら、 コメントよろしくお願いいたします。
YukiWikiにまたspam襲来。 いくつかは防いだのだが、新しいのは対処が遅れてしまいました。 まとめて削除してくださった方、ありがとうございます。
FrontPage, SandBox, Pythonなどの有名ページに追加しているらしい。
いま臨時に以下のような対処をしているのだが、 時間が取れたら整理して公開版に導入しようと思っている。
sub do_write {
if (&keyword_reject()) {
return;
}
if (&frozen_reject()) {
return;
}
# 略
}
sub keyword_reject {
my $s = $form{mymsg};
my @reject_words = qw(
51.net
shredder-for
paper-shredder
mail.ru
boom.ru
ここに拒否ワードを並べる
);
for (@reject_words) {
if ($s =~ /\Q$_\E/) {
&send_mail_to_admin($form{mypage}, "Rejectword: $_");
sleep(30);
return 1;
}
}
return 0;
}
追記
読者さんから「NGWordsのページを作って拒否ワードをメンテしては？」というアイディアをいただきました。 「ソース埋め込みでは管理しにくいのでは？」ということです。
結城もそれを考えたことがありますが、NGWordsをpublicにすると、 いろいろと問題（すり抜けしやすくなるなど）が起こりそうなので、ちょっと二の足を踏んでいます。 ソース埋め込みにはせず、別ファイル(たとえばreject.txt)にするのがよいかなあ、と思っています。 もしもWebで管理したければreject.txtを管理するツールを別途用意する、と。
何となく、思うことを書く。
私は「説明できないなら、理解していない」と思っている。 自分が理解していなければ、人に説明することはできない。 説明は、理解を前提とする。 それはプログラミングの話でも、文章の話でも、数学の話でも同じだ。 言い換えれば、自分が本当に理解しているかどうかを知りたかったら、 人に説明してみればよい。うまく人に説明できたら、自分も理解していることになる。 うまく人に説明できなかったら、理解していない可能性が高い。 読みやすい本を書こうとするときにも同じことが起こる。 自分が書いた本が読みにくかったら、それは自分の理解が足りないのだ。
（もちろん「人には説明できないけれど、自分としては理解している」という状況も考えられないではない。 でもそれを他人が検証することは難しい）
本を書くのは挑戦的だが楽しい作業だ。 それは自分の子供に何かを説明するのと似ている。 子供に何かを説明していると、思いがけない疑問を提示されることがある。 自分は、それに即答できるだろうか （少なくとも子供を納得させるだけの答えを返すことができるだろうか）。 うまく答えられるときもあれば、答えられないときもある。 自分としてはうまく答えたつもりなのだが、子供は納得しないときもある。 子供はその点において、よい話し相手になる。「わかったふり」をしないからだ。 良い編集者も同じかもしれない。「わかったふり」をせず、著者に 「ここは読みにくいです」と提示する役割。
子供が小学校で習ってくることでも、 改めて自分で説明しようと試みると難しい。 自分って本当にものを知らないのだと痛感する。
私は、自分で本を書いた範囲については一通り理解していると思っている。 つまり、C, CGI, Perl, Java, 暗号技術, Wikiなどに関してだ。 でも、それ以外のことはよくわからない。わからないことはたくさんある。 自分が「わかっているのかいないのか」がわからないこともたくさんある。
本を書き始めるときには「自分は、いま書こうとしている内容を理解している」と思っている。 でも、いざ実際に書いてみると「いや、ちがうな。私はよく理解していない」ということに気がつくことが多い。 説明が書けなかったり、書いても読みにくかったり、読み返して理解できなかったりするからだ。 そういう場合には、再度詳しく勉強する必要が出てくる。
何も書かれていない白い紙を机に広げる。 参考書も、コンピュータも机の上には置かない。 そして筆記用具を取り、説明の文章を書いてみる。 面倒だったら書かずに、説明の文章を声に出してみるだけでもよい。 大事なことは、頭の中で説明するのではなく、文字や音など「自分の外」に出すことだ。 ごまかさずに、よどみなく説明できるなら、よく理解しているといえるだろう。 つっかえったり、「たとえば」と言った後に言葉につまるようなら、本質を理解していないのだ。
いうまでもないけれど、自分をごまかすことはいつでもできる。 自分が理解しているふりをすることは簡単だ。 「これは当たり前のことだから説明不要」 といってしまえばよいからだ。
当たり前に感じることであっても、自分なりにきちんと説明しようと試みる。 その報酬は2つある。 1つは「自分は実は理解していないのだ」と気づくこと。 もう1つは「別世界への扉の発見」である。
別世界への扉？
自分が理解していないことを知り、改めて勉強する。 すると「当たり前だ」と思っていたときには通り過ぎていた場所に、 扉があることに気づく。 古ぼけた扉で、さびついていて、開きそうにない。 でも、引っ張ると、開く。こことは違う別世界がその先に広がっている。 それが「別世界への扉」だ。 開けるのはそれほど苦労はない。 必要なのはその扉の存在に気づくことなのだ。
私はそんな風に考えている。
かんさんの日記に「Googleで検索すると自分のサイトが一番になる言葉は何か」という話題が出ていて、 つい私も探してしまった。
（以下は、今日現在の検索結果です）
当然ながら 「結城浩」で検索すると一番に来る。 右に表示される広告にAmazonへのリンクが出てきたのにはちょっと驚いたけれど。
「結城」だけでも、結城市を押さえ、一番になるようだ。
「結」だけだと、残念ながら「結納」に負けてしまう。 (^_^;
「デザインパターン」はどうだろう。 試してみると、一番に来たのは… なんと ギコ猫とデザインパターンで、思いっきりこけてしまった。
追記
さて、そろそろ寝ようかな、と思ってメールチェックしたところ、 読者さんから、
ギコ猫でも一番にきてしまいますよ（笑
というご指摘が… (^_^; 。
では、おやすみなさい。
私「普通の生活では「速さ」というけれど、物理ではもう少し厳密な用語を使う。速度や加速度などだね」
長男「ふうん」
私「速度って何だか覚えてる？」
長男「ええとね、位置の変化、だっけ」
私「そうそう「位置の変化」が「速度」だ」
長男「加速度は？」
私「加速度は「速度の変化」のことだ」
長男「ふうん」
私「三つの量の関係がわかるだろうか」
長男「どういうこと？」
私「位置→速度→加速度という三つの量。位置の変化が速度。速度の変化が加速度」
長男「ねえ「加速度の変化」っていうのもあるの？」
私「それはよい質問。うん、あるよ。イメージがわきにくいし、特別な名前はないけれどね（※加加速度というそうです）。ところで、物理では力を加えなければ、速度は変わらないことを学ぶ」
長男「うーんと…、あ、それは摩擦がないときの話だね」
私「その通り。力を加えなければ、物体は静止しているか、等速直線運動をする」
長男「そうだね」
私「これは誰が見つけたんだろう」
長男「えっとー。ガリレオ」
私「何の法則？」
長男「慣性の法則」
私「その通り。速度を変えるためには、力を加える必要がある。そのためにはエネルギーが必要になる（※仕事については省略）」
長男「ふんふん」
私「たとえば自動車。ガソリンを使って走る。ガソリンの化学的エネルギーを変換して走る」
長男「エネルギーはなくならないの？」
私「なくならない。姿を変えるだけだ（※E=mc^2の話は省略）」
家内「でも、車が走った後、エネルギーはどこに行ったの？」
私「音になったり、熱エネルギーになって周りの温度を高くしたりする」
家内「…（納得していない）」
私「人間には使いにくいエネルギーの形になっても、エネルギーがなくなったわけではない。人間にとって使いやすいかどうかということを表現するためには「エネルギーの量」だけでは面倒。そのためにエントロピーという…（以下略）」
* * *
私「さっきの話に戻るけれど、位置から速度を求めることと、速度から加速度を求めることは、数学的には同じだ」
長男「へえ」
私「この計算が、微分なんだ」
長男「えっ？！」
家内「そうなのっ？！」
私「位置を微分すると速度、速度を微分すると加速度が求められる」
長男「積分はどうなるの？」
私「それはとてもよい質問。積分は微分の逆演算。加速度から速度、速度から位置を求めるのが積分」
長男「へえ」
位置→（微分）→速度→（微分）→加速度 位置←（積分）←速度←（積分）←加速度
私「中学校で位置・速度・加速度は学ぶけれど、微分積分は学ばない。でも、微分積分のことがちょっとわかっているだけで見通しがよくなる」
家内「そうね」
私「それはちょうど、つるかめ算と似ている。小学校でつるかめ算は学ぶけれど、連立方程式の解き方は学ばない。実は、連立方程式の解き方がちょっとわかっていると、つるかめ算専用の特殊な解き方を覚える必要はなくなるし、かしこい子にとっては理解が深まる」
家内「ふうん」
手元にRSSのURL一覧があるとする（たとえばKissReader用に作ったもの）。 i-know.jpにそのRSSをまとめて登録したいとする。
i-know.jpではLIRS形式のデータをインポートできるから、 RSSのURL一覧をLIRSに変換すればよい。
たとえばこんなPerlのスクリプト(lirs.pl)を用意する。 RSSのURL一覧はスクリプトの末尾に追加する。
while (<DATA>) {
chomp;
next if /^#/;
print qq(LIRS,0,0,0,0,$_,0,0,$_,0,\n);
}
__DATA__
# この後に購読したいRSSのURLを追加。URL中の , は \, とすること。
https://www.hyuki.com/diary/rss
https://www.hyuki.com/tf/?rss
このスクリプトを動かすと標準出力に以下のような出力が出るから、 リダイレクトしてファイル（たとえばlirs.txt）に落とす。
LIRS,0,0,0,0,https://www.hyuki.com/diary/rss,0,0,https://www.hyuki.com/diary/rss,0, LIRS,0,0,0,0,https://www.hyuki.com/tf/?rss,0,0,https://www.hyuki.com/tf/?rss,0,
あとは、i-know.jpの「アンテナ編集」 を使って、ファイルlirs.txtを送信すればよい。
なお、上のスクリプトの出力は、LIRS形式としてはいいかげんです。 作ってi-know.jpに送信したら登録されたよ、 というだけのことです。ご了承ください。
正しいLIRSの仕様は以下のリンクをご覧ください。
夕方、ふと思い立ってセンター試験の数学Iをやってみた。 時間は60分。
2次方程式の解の公式や三角関数の公式などはすっかり忘れていたけれど、 時間中に導出。確かめをして計算間違いを見つけるなど、 余裕だぜとほくそえみつつ答えあわせをしたら、 ケアレスミスで満点にはならず。
すごく悔しい。
ついさっき、freeml.comでメーリングリスト管理の作業をしていたら、 いつのまにか、JWordがインストールされていた。 ちょっと「むっ」ときて、コントロールパネルを開いて、すぐアンインストール。
Windows XPの場合のアンインストール手順は：[設定]→[コントロールパネル]→[プログラムの追加と削除]→[JWord]→[変更と削除]
どこかで間違ってインストールするリンクをクリックしたのかなあ、と思って 再度freeml.comにいってみた。 なんと、トップページに行くだけでJWordがインストールされてしまう！
3回試して確認し、3回アンインストールした。 やれやれ。
章扉のコンテを書いて、編集部へ送付。
2003年に「キッズgooのフィルタリング」の不思議さについて書いた。
今日、ふと、同じページを試してみることにした。 以下のようになった。 OK→NGになったものが3個あるほかは以前と同じ。
追記
なんばさんから「秘密」がNGワードではないか、というご指摘がありました。 なるほど。『暗号技術入門 —— 秘密の国のアリス』の「秘密」が効いているのですな。
手元にRSSのURL一覧があるとする（たとえばKissReader用に作ったもの）。 RSSアグリゲータのBloglinesにそのRSSをまとめて登録したいとする。
BloglinesではOPML形式のデータをインポートできるから、 RSSのURL一覧をOPMLに変換すればよい。
たとえばこんなPerlのスクリプト(opml.pl)を用意する。 RSSのURL一覧はスクリプトの末尾に追加する。
print qq(<?xml version="1.0"?>
<opml version="1.0">
<body>
<outline title="Subscriptions">
<!-- begin -->
);
while (<DATA>) {
chomp;
next if /^#/;
# s/&/&/g;
print qq(<outline type="rss" xmlUrl="$_" />\n);
}
print qq(<!-- end -->
</outline>
</body>
</opml>
);
__DATA__
# この後に購読したいRSSのURLを追加。URL中の&は&とすること。
https://www.hyuki.com/diary/rss
https://www.hyuki.com/tf/?rss
このスクリプトを動かすと標準出力に以下のようなXMLを出力するから、 リダイレクトしてファイル（たとえばrss.xml）に落とす。
<?xml version="1.0"?>
<opml version="1.0">
<body>
<outline title="Subscriptions">
<!-- begin -->
<outline type="rss" xmlUrl="https://www.hyuki.com/diary/rss" />
<outline type="rss" xmlUrl="https://www.hyuki.com/tf/?rss" />
<!-- end -->
</outline>
</body>
</opml>
あとは、Bloglinesの「登録」
http://www.bloglines.com/import
を使って、ファイルrss.xmlを送信すればよい。
なお、上のrss.xmlに出ている情報は、Bloglinesからエクスポートしたときの情報よりもずいぶん少ないけれど、 ちゃんと登録される。サイトのタイトル情報などはBloglinesのほうでサイトにアクセスしてとってくれるから、 インポートするファイルには、typeとxmlUrlさえちゃんと書かれていればうまくいくようである。
JavaScriptで'n'や'p'を使ってページ制御する機能は Mozillaのインクリメンタルサーチの機能と干渉してしまうというご報告をいただきました。 また、'<'や'>'で先頭・末尾へ行くのはHomeキー、Endキーですでに実現しているUser Agentが多いので、 特別にJavaScriptで提供する必要はないのでは、という意見も。
ちなみに私が考えた「解決策」は次の4通り。
不都合が生じるユーザがいるということがわかったので、 「JavaScriptによる簡単なページ制御」はデフォルトでは無効にし、 ページ右上の (keynavi) という部分をクリックすると有効になるようにしてみました(上の3.ですね)。 また、'<', '>', '.'のナビゲーションはやめました。
これなら、この機能を使いたい人（で右上の(keynavi)って何だろうと気づいてくれた人）は使えるし、 使いたくない人や興味のない人には影響がないと思います。
今回の「JavaScriptによる簡単なページ制御」に関しては、
多くの方からていねいなフィードバックをいただきました。
お一人一人にお返事できず、申し訳ありません。
でも、とても感謝しております。
また、どんなことでも構わないのでご意見をお寄せくださいね。
(^_^)
今日は、ソフトバンクパブリッシングへ行き、 C MAGAZINEの連載について編集者さんと打ち合わせをしました。 その後、いつも拙著を売ってくださっている営業の方々にごあいさつをしてきました。 単に儀礼的なあいさつがなされたのではなく、 営業の方から、「新刊の読者層」をはじめとする具体的で真剣な質問をいただきました。 一冊一冊の本をきちんと読者に届けようという気持ちが伝わってきて、 とてもうれしく、また頼もしく思えました。 今後とも、よろしくお願いいたします。
今日は打ち合わせ。 打ち合わせのための資料を作る。
打ち合わせでは、と書きかけて、以前似た日記を書いたことを思い出した。
2002年の日記だった。時が経つのは早い。
読者さんから
はじめまして、いろいろなソフトを作りたいと思い、今Javaを独学で勉強してます。 今、勉強に使っているJava基本の参考書が、私にはちょっと難しかったものでして、 分かりやすい本はないかと思い、インターネットを検索してみて結城さんの本にたどり着きました。
私自身も実際に本屋で目を通してみて、とても分かり易い！！と感じました。 まさに評判どおりの本でした
そこで結城さんの本で、Javaを頑張って覚えようかと思います。
↓
↓
『Java言語で学ぶデザインパターン入門 マルチスレッド編』
の順番で勉強し、あとは人の作ったソースを研究しようと思ってます。
サーブレットというは別として、これでJavaをある程度はマスターできますでしょうか？
結城から
こんにちは。 拙著を気に入ってくださったようで、ありがとうございます。
Javaは現在、携帯からサーバーサイドまで幅広く使われているプログラミング言語ですね。 あなたがどのようなソフトをお作りになりたいかはわかりませんが、 Javaを学んで損はないと思います。
さて、お尋ねの件ですが、 『改訂版Java言語プログラミングレッスン』の上下を読み終えたあと、 『増補改訂版Java言語で学ぶデザインパターン入門』を読むのはよいことだと思います。 でも、人の書いたソースを読むのは、本を読むのと並行して進めるとよいと思いますよ。
抽象クラスやインタフェースの存在意義を理解し、 オブジェクト指向プログラミングで出てくる多くの考え方を学ぶために、 『増補改訂版Java言語で学ぶデザインパターン入門』はよい本だと思います。
マルチスレッド編もよい本です。 こちらはマルチスレッドプログラミングを学ぶ本になります。 これは、オブジェクト指向とは違った視点からJavaをとらえているといえるでしょう。 マルチスレッド編は、 少しプログラミングの経験を積んでから読んだほうがピンと来るかもしれません。
どんな本でもそうですけれど、学ぶ人との相性というものがありますから、 購入前に書店でパラパラ見て、 現在の自分で読み進められそうかと見当をつけることをお勧めします。 他の人がどう言おうとも、自分が読んで理解できなかったら、 （すくなくとも現在の）自分の役には立ちませんよね。 その見極めはとても大事です。
さて、そのほかに、 Eclipseなどの開発ツール, JUnitなどのテストツール, ネットワークの話, GUIの話, ...なども学んでいくことになるでしょうけれど、 あまり最初からたくさん詰め込んでパンクしたりしないように。 むしろ 『Java言語仕様』を読んだり、 JDKのリファレンスマニュアルを読んだほうが勉強になるかもしれません。 少なくとも、私の場合はそうでした。 私は、 The Java Language Specificationをダウンロードして読み、勉強しました（当時はSecond Editionではなかったですけれど）。
どの本をどれだけ読めば、どの程度Javaを身につけられるのか、 というのは個人差がありますのでなんともいえません。ごめんなさい。
忘れてはいけないのは「自分の頭で考える」ということです。 本やツールも大事ですが、 それはあなたが自分の頭で考えることを助けてくれるだけです。 本やツールはあなたの頭の代わりにはなってくれません。 じっくり、自分の時間をかけて「自分の頭で考える」必要があります。 そのことを忘れると、世の中にあふれかえっている技術情報に翻弄されて疲れてしまいます。
プログラミング言語の本は「読む」だけでは駄目で、 実際に自分の頭で考え、手を動かしてやってみることが必要です。 『改訂版Java言語プログラミングレッスン』のはじめのほうでも、 私は「覚えること・考えること・やってみること」と書きました。 この3つを心がけて、勉強を進めてください。
Enjoy Java!
章扉のコンテを書く。残りの章全部。 一日寝かせてから編集長あてに送付する予定。
結城が持っていたGmail Invitationsの権利3個分は、 連絡くださった方に先着順でお送りしました。 ご応募・応援メッセージをありがとうございました。 間に合わなかった方、ごめんなさい…。
結城の手元にGmail Invitationsが3個あります。
以下のフィードバック欄からご連絡くだされば、どなたでも希望なさる方に差し上げます。
完全先着順。
必須な情報は、あなたの (1) First Name, (2) Last Name, (3) Email です。
できましたら、いきなり「希望」と書くだけではなく、あなたがどんな方であるか、
それから結城のページのどんなところを読んでいらっしゃるかなどを多少書いてください。
（食卓にて）
長男「ねえお父さん、ナンプレやろう！」」
私「今日はもういいや。ナンプレを解くプログラムってあるんだよ」
長男「えっ！ …どうしてコンピュータにそんなことができるの？」
家内「2人とも、早くお風呂にはいってちょうだい！」
（お風呂に移動）
私「足し算と掛け算はどこが似ているだろう？」
長男「簡単。ええと整数…自然数同士を足したらもとの数以上になる。自然数同士を掛けたら元の数以上になる」
私「ほほう、なるほどね。他には？ たとえば引き算や割り算と比べると？」
長男「うーんとね…自然数同士の掛け算や足し算はいつでもできるけれど、引き算や割り算はできないかもしれない。ほら、小さな数から大きな数を引けなかったり、割ったときに割り切れなかったりするから」
私「なるほど！そりゃすごいな。確かにそうだ」
長男「あとは、何かある？」
私「じゃあヒント。a+bとb+aについて考えてみよう」
長男「わかった！逆にしても同じ。掛け算と足し算どちらも、逆にしても同じになる」
私「そうだね。引き算や割り算は同じになるとは限らないね」
長男「他には？他には？」
私「じゃあこんどはa+b+cについて考えると？」
長男「カッコをどこにつけても同じだね(a+b)+cとa+(b+c)は同じ。」
私「そうだね。これは結合法則というよ。さっきのa+bとb+aが等しくなるのは交換法則。ところで(a÷b)÷cとa÷(b÷c)は本当に違うの？」
長男「（天井を見上げる）ええと、じゃあ(6÷3)÷2を考えると、2÷2で1になる。6÷(3÷2)は…割り切れないよ」
私「3÷2は2分の3だね。6を2分の3で割るということは、6に3分の2を掛けるってことだから…」
長男「6を3で割ると2。2×2で4になる。さっきの1とはやっぱり違う答えになるね」
私「そうだね」
長男「さっきの…結合法則だっけ。名前忘れたけれど、法則はもう1つあるよね。(a×d)+(b×d)+(c×d)が、(a+b+c)×dになるの」
私「それは分配法則だね。dをこう…分配してあげるの。分け分けするんだね」
長男「ところで、さっき言ってた話だけど、ナンプレを解くプログラムってどうすればできるの？」
私「そうだねえ。コンピュータは簡単なことしかできないけれど、それを複雑に組み合わせることや、人間にはできないほどのスピードでこなすことは得意だよ」
長男「うんうん」
私「だから、計算をどのように進めるかということを、きちんと言葉で書き表すことができるようなことは、コンピュータにもできる」
長男「じゃあさ、たとえば「絵を描く」っていうのはどう？コンピュータにもできる？」
私「それは、「絵を描く」の定義による」
長男「そうかなあ。絵を描くのはできないと思うけれど…」
私「たとえばカメラでパチリと」
長男「そういうの、なしだよ〜」
私「だから、「絵を描く」というのはどういうことなのかを定義しなければ、できるとも、できないともいえない」
長男「そりゃ、そうだけど」
私「たとえば、画像データになっているものを「油絵風」にしたり、「スケッチ風」にしたりすることはコンピュータにもできる」
長男「まあね」
私「でも、そうだなあ…。小さい子が描くような絵をコンピュータに描かせるのはちょっと難しいかも」
長男「どうして？」
私「そういう絵を描くには、どういうふうに描いたらいいのかを、言葉で説明することが難しいからだ」
長男「そりゃそうだね。じゃあ、家の見取り図みたいなものを描くのはどう？」
私「うん、コンピュータにはそっちのほうが得意かも」
長男「どうして？ あのね、傾いたり、倒れたりしない家を作るんだよ」
私「かなりの部分が計算できると思うから、コンピュータでもけっこういけるんじゃないかな」
長男「そうかなあ」
私「概して、大学で勉強するようなことはコンピュータも得意。でも幼稚園でやるようなことはコンピュータは苦手なんだ。何だか逆みたいだけれど」
長男「どうして？」
私「大学で勉強するようなことの多くは言葉で伝えることができる。でも幼稚園でやることはうまく言葉で伝えられず、やっている子たちも無意識のうちにやっていることが多くあるからだよ」
長男「ふむふむ」
私「絵本を読んで聞かせて「どうしてこの子は泣いたのかなあ？」と尋ねたときに答えられるコンピュータを作るのは難しいと思う」
長男「なるほど。たしかに難しそう…。」
私「チューリングという人は、コンピュータが考えるかどうかを判定するテストを考案した。チューリングテスト、という。」
長男「チューリングテスト？ 聞いたことあるなあ」
私「前もお風呂で話したことがあると思うよ」
長男「どういうテスト？」
私「2つの部屋があって、片方には人間、他方にはコンピュータが入っている。そのほかに判定する人が1人いるけれど、その人は、どっちの部屋にコンピュータがいるかを知らない。判定する人は、タイプを使って通信して、その部屋の中の人間やコンピュータと対話する。そして、判定する人が「どっちの部屋にコンピュータがいるか」を当てられなかったら、そのコンピュータは「考えている」と判断しよう…これがチューリングテスト」
長男「え？ 判定するのに、人が必要なの」
私「それはなかなか鋭い指摘だけれど——チューリングテストでは人が必要だね」
長男「だって、計算問題を出したら、コンピュータはすぐに答えちゃうじゃない。すぐにわかっちゃうよ」
私「あ、そうそう。コンピュータは「できるだけ、人間のふりをする」んだよ。だから、計算問題にわざと遅く答えたりしても良い。ときどきは間違えたりしてね」
長男「えええ！ わざと間違ってもいいの？」
私「そう。あなたがその判定者だったら、何て質問する？」
長男「簡単だよ。「あなたは人間ですか？」って聞く」
私「でも、両方とも「そうです」と答えるかもよ」
長男「人間は即座に答えられるじゃない」
私「いや、コンピュータは人間と同じくらいの速さで答えられると思うよ」
長男「じゃあ、「あなたは考えていますか」って…あああ、これでもだめだなあ」
私「こういうのはどうだろう。「あなたのお父さんのことを教えてください」」
長男「あ、そうか。コンピュータにはお父さんがいないから」
私「でも駄目だよ。だって適当なお話を作り出すかもしれないからね」
長男「ううう。ところで、そんなコンピュータって本当にあるの？」
私「だから、そういうコンピュータがあったとしたら、それを「考えている」ということにしようというんだよ」
長男「そっかー」
私「それがチューリングテスト」
上の日記を書いてから、 Wikipediaの「チューリング・テスト」の項を読んでいて、「中国語の部屋」というのを見つけた。 まあ、チューリング・テストのman-in-the-middleみたいなもの（違うって）。
結城が用意していた解答:
(1) 案内文の前半にある「暗号化は正常に行われます」は正しいでしょうか。
正しい。
この警告は「証明書の署名をたどっても、信頼できるCAまでたどりつけない（信頼できるCAによって署名されていない）」ことを意味します。 証明書が信頼できるCAによって署名されていないからといって、 暗号化が無効になるわけではありません。
ただし「正常に」という表現に「正しい相手と」という意味を含めたいとするなら （すなわち認証の意味も込めたいなら）、 「暗号化は正常に行われます」という表現は正しくありません。
(2) もしも「はい」で進み、住所を入力したとすると、どんな危険が考えられるでしょうか。
通信しようとする相手は、予期せぬ相手（たとえば悪人）かもしれません。 その相手に住所を知られてしまう危険が考えられます。
セキュリティの「危険」について考えるときには、必ず「誰にとっての危険」なのかを意識しなければなりませんが、 ここでは、住所を入力した人にとっての「危険」に限って考えました。
向井さんからの解答:
クイズの解答に挑戦してみます。 1. 暗号化はされている。中途の経路で何者かに盗聴される危険性はない。 2. 宛先が本当の相手かどうかがわからない。通信先は他人が作った偽造サイトかもしれず、 その場合は入力した住所が本来届けたい相手には届かず、偽物の手に渡ることになる。 だと思うのですが。
ぼあろさんからの解答:
暗号化通信自体は、正常に行われるのではないでしょうか。 この部分は、証明書が正しいかどうかとは無関係に思えます。 あれ。でも高木浩光さんの日記には「暗号自体も問題あると思う」と書かれていますね。 私、なにか勘違いしてますね・・・よくわかりません。どういうことなのだろう。 その後の住所入力については、危険だと思います。 が、なぜかと聞かれると… 難しいです。 解答になっていないですね。すいませんでした。 以下、少し違う話ですが。 高木浩光さんの文章を読んでいて、認証というものがなんだか良く分からなくなってしまいました。 というか、自分がほとんど理解できていないんだな、と。 結局、その認証局が信頼できるかどうかは、自分で判断しなければいけないのですよね。 ベリサインだろうが、LGPKIだろうが、その他の認証局だろうがそれは同じだと思います。 ベリサインの場合は、マイクロソフト（IEに最初から入っている）のおかげで、 利用者がベリサインのことをよく知らなくても、 「ああそうか、ベリサインは信頼できるのか」と“思い込んでしまう”ということがあると思います。 実際に信頼できるところなのかもしれませんが、私はよく知りません。 まぁそれでも、“比較的”信頼できる、ということなのでしょうか。絶対などありませんからね。
小町潤さんからの解答:
「オレオレ証明書」に「はい」で答え、住所などを記入した場合の危険性： ・見ず知らずの人（その人が信頼するに足りる人かどうかも吟味していない） に自分の情報を提供することになる だいぶ前から心配に思っているのですが、証明書発行機関って、 証明書を発行して欲しい組織や個人の身元を証明することはできるかもしれませんが、 信頼していいかどうかは証明できませんよね。 例えば「結城浩」をもじった「結減浩」なる人物が勝手にサイトをつくり、 証明書も発行されて、個人情報を集めようとした場合、 「結城浩」と「結減浩」の見分けがつきにくいことにより、 多くの人が騙されてしまう可能性があります。 偽ブランドみたいなもので「SONY」を「SOMY」とか、 「SHARP」を「SHORP」のように見分けのつきにくい名前をつければ、 証明書の効力は落ちると思います。
しが・ただすさんからの解答:
オレオレ証明書クイズの答案です。 (1) 暗号化は正常に行われる。 (2) データの送り先のサーバが自分の送ろうとしたサーバではない「偽のサイト」である可能性がある。 ただ、「信頼された認証局」から発行された証明書をつかっても 僕たちはいちいち認証局自体の信頼性を評価しているわけではありません。 もしかしたら偽の認証局が入っているかもしれません。
他の方々の解答:
補足： 認証の問題はとてもとても難しいです。 大きく「認証局が信頼できる」というだけではなく、 その認証局の「運用規定」も考慮に入れる必要があります。 また、有効期限内にある証明書であっても、 すでに破棄されている可能性もありますので、 CRLのチェックも必要になりますね。
「まちゅダイアリー」に書かれていた 「こうやって、何が問題かを自分の頭で考えることは大切だろうね」というコメントは、 我が意を得たりという感じです。ありがとうございます。
なお、このクイズに関連して、多くの方から、 拙著『暗号技術入門』 への応援メールをいただきました。 たくさんの方から読まれていることに驚きつつ、 また感謝の気持ちでいっぱいになりました。 みなさんありがとうございます。
以下もお読みください。
読者さんから、 「フィードバックで文字を入力しようとすると、n, p, .などが持っていかれてしまう」と報告が。 にゃるほど…。うう。調査、調査…。
（ややあって）
いちおう直してみました。
章扉のコンテを書く。1章から3章まで。
試験的に、'n'と'p'という2つのキー操作で、 日記ページ内を巡回できるようにしてみました('n'と'p'はEmacsのキーバインディング)。 JavaScriptをOnにしている人は、'n'と'p'のキーを打ってみてください。
Internet Explorer, Lunascape, Firefoxで動作を確認しました。
なお、この修正についてはせきむらさんの「RSS Rolling みたいの」を参考にしました。 感謝します。
n --- 次↓の記事 p --- 前↑の記事 < --- 先頭 > --- 末尾 . --- 現在の記事
加筆
kayakayaさんから、 「Operaでは'p'キーが印刷プレビューに割り付けられているため'p'が使えない」 というレポートが。 「Sleipnir 1.66では正常に動作」とのこと。 感謝します。
ではvi風に'n'と'N'（それとも'j'と'k'かな）に…（思案中）。
高木さんによる以下のページは、 「セキュリティの警告（けいこく）メッセージが表示されることがありますが、問題ありません」 という「埼玉県 わくわくこどもページ」の話題です。
笑っている場合ではないのだが、 高木さんと担当者とのやりとりは、まるで漫才のよう。 いろんな意味で貴重な記事ですね。 やりとりが漫才のようになるのは、 「実際に問題がある証明書」を「問題がない」と主張することが無理だからでしょう。
いつみゆうさんは、 正しく検証できず、受け入れるかどうかを状況でのみ判断しなければならないサーバ証明書のことを 「オレオレ証明書」と表現しました。 これは非常にうまいネーミングですね。
さて、高木さんの日記はごらんになったでしょうか。 やりとりで笑うだけではつまらないので、 ここで読者のみなさんにクイズを出すことにしましょう。
オレオレ証明書クイズ
【クイズ】あるWebサイトに、
セキュリティの警告メッセージが表示されることがありますが、 暗号化は正常に行われますので、「はい」でお進みください。
という案内文が書かれていたとします。 そこにある「住所の入力」というリンクをクリックすると、 以下のような警告が表示されました。
(1) 案内文の前半にある「暗号化は正常に行われます」は正しいでしょうか。
(2) もしも「はい」で進み、住所を入力したとすると、どんな危険が考えられるでしょうか。
※注意: 送ってくださった解答は日記で公開する場合がありますので、 そのことをご了承の上、送信してください。
やねうらおさんの日記を読んで、受験シーズンに気づいた。 受験生のみなさん、がんばってください。 実力を十分に発揮できるように祈っています。
僕は、みずうみのほとりを歩いている。
空は青く、水は深い。
妖精がひとり、歌を歌っている。
軽やかなステップを踏みながら。
メロディは、いまでも覚えている。
先日書いた「情報共有と電話の回数」の問題は、2*N-4(N>=4)になるという定理があるそうです（ゴシップ定理？）
Wataru's memoが更新されている。 以前の記事も眺めていたら、 昨年10月の GCCプログラミング工房連載休載に関する文章(Breathing)の中に、素敵な文を発見。 連載と書籍との違いに触れた部分。
著者は読者に対して、ひとつの物語を提供しなければならない。
RSSの文字コードをShift_JISからUTF-8に変更した。
いろいろと多忙なり。
長男が2人の友達と遊ぶのに、電話でアポを取っている。 最近の子は忙しいので電話を使うんだねえ。
長男「（電話で）うん、じゃあ。○○ちゃんから掛かってきたらそっちに電話するね（切る）」
私「3人の友達が電話で遊ぶ打ち合わせをするのに、全体では何回掛ける必要があるだろう」
長男「少なくとも何回か？ってこと？」
私「そう」
長男「3回」
私「え？ 4回必要じゃない？」
長男「そんなことないよ。打ち合わせた結果を戻せばいいんでしょう？」
私「A, B, Cの3人がいて、AとBが打ち合わせして、AとCが打ち合わせをして、Aがその打ち合わせの結果をBに戻す…そうか、3回で済むね」
長男「4人ならどうなる？4人がそれぞれ秘密を持っていて、みんなが自分以外の3人の秘密を知るために電話をする回数は？」
私「それはいい問題だな。ええと…6回電話すれば大丈夫なのはすぐにわかる」
長男「それより少なくはならないの？」
私「どうだろう。（紙を配る）」
長男「何、この紙」
私「いや、書いて考えたいかな、と思って」
長男「（長方形の頂点にA, B, C, Dと文字をふった図を書き始める）」
私「（考えて）うん。6回よりは少なくならないな」
長男「そう？」
私「うん。証明できる」
長男「へえ…」
私「あのね」
長男「待ってよ。いま考えているんだからさあ」
私「へいへい」
長男「全部の対角線を結べばよさそう」
私「ああ、そうだね。 完全グラフっていうんだよ。perfect graph. 対角線の本数だけ電話を掛ければ、情報が全員に行き渡ることはわかる。十分条件はそれでいい。 でも、もっと少なくできないだろうか」 （加筆: 読者さんから、perfect graph→complete graphというご指摘をいただきました）
長男「（図を描いている）うーん」
私「少なくはできない。N人の場合も証明できるよ」
長男「え、本当？」
私「0からNまでの和でいい」
長男「駄目だよ。それじゃ4人の時には10になっちゃうじゃない(0+1+2+3+4=10)」
私「あれ？…あ、ごめん。0からN-1までの和だった」
長男「やれやれ」
私「証明もできるよ」
長男「1人のときは…0回の電話でいいね。2人のときは1回」
私「3人のときは3回。4人のときは0+1+2+3=6で6回」
長男「ふうん」
私「N人の人がいて、その人たちはみんなすでに秘密を共有しているとする。そこにもう1人の人がやってきたとする」
長男「なるほど。その人のことを知るのにN回電話が必要なんだね」
私「その通り。情報がどこかでまとまるとしても、N人の人は少なくとも電話を1回取らなければ、新しい人の情報は得られない。これで必要条件のほうもいえる」
（ここで、電話がかかってきて、長男は遊びに行ってしまった）
N人の人がそれぞれ持っている情報を、
電話を使って全員が共有するために必要十分な電話の回数は、
回。
証明は数学的帰納法。
加筆
複数人の読者さんから、上記の
というのは不十分/誤りというご指摘をいただきました。
簡単に書きますと、
「N人の人がすでに秘密を共有しており、そこにもう1人の人がやってくる」という状況と、
「N+1人の人が秘密を共有する」という状況は等しくないということです。
たとえば「A,B,Cの3人がすでに秘密を共有しており、そこにDがやってきた場合」は、 確かに全部で6回必要です。
でも、「A,B,C,Dの4人が最初からいる場合」あるいは「A,B,Cが秘密を共有している途中でDが加わった場合には」 5回の電話(AB, AC, AD, AB, AC)で共有が可能です。 2パスだと思えば、すぐに理解できます。 AB, AC, ADまで進んだところで、Aには全員の情報が集約され(1パス目)、 もう一度AB, ACまで進めば、Aはその情報を全員に供給することができます(2パス目)。
ということで、 N人の人がそれぞれ持っている情報を、 電話を使って全員が共有するために十分な電話の回数は、 N=1のときは0回、 N>=2のときは(2N - 3)回。
ええと、では、必要な電話の回数は？
加筆
何人かからお便りをいただきましたが、 以下、上原さんからのメールを許可を得てご紹介いたします。 複数回いただいた情報を、結城の方でちょっと編集しました。 上原さん、みなさん、ありがとうございます。
結城さんの今日の日記の「情報共有と電話の回数」について，
ちょっとコメントなのですが，4人の場合，以下の方法なら5回で済みます．
1. A←→Bで電話して，情報{a,b}を共有
2. A←→Cで電話して，情報{a,b,c}を共有
3. A←→Dで電話して，情報{a,b,c,d}を共有
4. A←→Bで電話して，情報{a,b,c,d}を共有
5. A←→Cで電話して，情報{a,b,c,d}を共有
結城さんの証明と，上の方法を見て，よ〜く考えてみると，
- 最初から N 人いる場合
- 新しく人が来る場合
とでは，別の結果になりますね．上記の方法だと 2N-3 回で済むなぁ…．
. . .
回数は減ってるんですが，システム全体を流れる情報の量が
微妙に増えているところもおもしろいですね．
. . .
「十分な電話の回数」は 2N-3 ですが，
「必要な電話の回数」も 2N-3 になりますね．
以下，簡単な証明です．
まず，最初に全員の情報を知る人を x とします．この人が最後に
会話を交わした人を y とすると，x,y は同時に全員の情報を知ります．
どんな人も，x に情報を渡すためには，必ず 1 回電話をしなくては
ならないので，x,y の会話以前に最低 N-2 回の会話が必要です．
この時点で，N-1 回の会話が必要です．
同様に，x,y 以外の N-2 人の人が x,y の持っている情報を知るためには，
このあとに最低 N-2 回の会話が必要です．
そんなわけで，トータルで 2N-3 回の会話はどうしても必要になります．
…ってなわけで，2N-3 回が必要かつ十分ですね．
おまけですが，人々がバイナリツリー(根のところがちょっと違いますが)の
node になって，
1. 葉から根に情報を集める
2. 根から葉に情報を送る
という戦略で電話をすれば，全員が情報を知るまでのトータルの時間が
O(log N)になって，最適ですね!!
さらに加筆(2005-01-11 02:40)
ytsさんから、 以下のような意見が…。 以下の図では、12人(*印)が情報を共有するのに、確かに20回で済みますね。 うう、難しい問題なんですね。
結城さん
最初に全員の情報を知る人は一組とはかぎらないのではないでしょうか。
このグラフだと、20 < (2 * 12 - 3 = 21)回で連絡できていると思います。
* * * *
\ / \ /
* ---- *
| |
* ---- *
/ \ / \
* * * *
またまた加筆、というかリンク発見(2005-01-12 00:16)
さらにリンク(2005-01-13)
hirax.netに書かれていた「円周率は約3でいいか」というフレーズを読んでいて、 以前長男に「円周率が3だったらどうする？」と尋ねたことを思い出した。 長男の答えは「正六角形を円と呼べばいい」だった。
追記
この記事に触発されたらしい はてなの質問が出ていました。
日記のCGIを少しいじってmimeTeXが使えるようにした。
柑橘系の香りのミルカさんがノートにメモしたのは、
という2つの式だ。
自分のサイトの簡易表記というのが、 一部で「はやって」いるようなので、試しにここでもやってみましょう。 もちろん、[結]で。
先日の 永遠についてという日記に対して、読者さんからコメントをいただきました。 ありがとうございます。
いつのまにか、KissReaderがYahoo!JAPANに登録されているのを発見。
www.textfile.orgを模様替えしました。 モジュールを使って統一的なインタフェースにした上で、 スタイルシートを少しいじりました。
読者さんから
オー・ヘンリーの『賢者の贈り物』を自分で翻訳して利用したいと考えています。 結城さんの訳の版権表示を読むと、原作者の著作権はもう失効しているようです。 私が翻訳するときも、許可をとる必要はないということでしょうか。
結城から
オー・ヘンリーの没年などから、私はそう理解しています。 ただし、これはあなたに対して何も私が保証するものではない、 ということはご理解ください。At your own riskでどうぞ。 オー・ヘンリーの原文は、あちこちのWebサイトで入手できます。 ちなみに、翻訳自体は何の許可も不要です。 問題になるとしたら、その翻訳のネットで公開するなどの「利用」のときです。
翻訳、がんばってくださいね (^_^) 。
今日は寒い。
次の本（あるいは次の次の本）について、本を読んだり、 メモを取ったり、図を描いたりしてお勉強。
2004年9月〜12月の、アマゾン注文ランキング(トップ10)です （結城の本を除いてみました）。
『セマンティック・ウェブのためのRDF/OWL入門』は、神崎さんの新刊。
『The Girl Who Loved Tom Gordon』はスティーブン・キングの本ですが、 ポップアップ絵本風になったバージョンらしいですね。
『急行「北極号」』は、映画「ポーラー・エクスプレス」の原作。 村上春樹の翻訳です。
何だか、頭がまわらないので、思いつくまま日記を書いてみようと思います。
ふと「永遠というのは、時間の長さのことではない」と思いました。 私たちが感じる「時間」を引き伸ばした先に永遠があるのではないように思うのです。 …などということを考え始めたのは、はちこさんが書いていた日記を見てからでした。 ちょうど数日前、『コンピュータ科学者がめったに語らないこと』を再読していて、 いわゆるスーパーKという、とてつもなくとてつもなく大きな数について思いを寄せていたせいもあるかもしれません。 あるいはまた、最近ずっと、カントールの「無限」について考えていたからかもしれません。 それはともかく。永遠というのは、時間の長さのことではない、と思いました。 ルイスだったと思うけれど「作者は、物語を書いているとき、物語の時間の外にいる」ということを書いています。 物語の中ではたった一秒の時間であっても、作者がその場面を書くときには好きなだけ時間をかけることができる。 思う存分その登場人物について考えることができる。 登場人物が一度まばたきをする間に、その人物の越し方行く末について考えることができる。 時間をかけることを愛と表現するならば、作者は登場人物に好きなだけの愛を注ぐことができる。 それは、物語の時間と、作者の時間は別次元にあるからだ。 私が「永遠というのは、時間の長さのことではない」といいたいのは、そういう意味だ。 永遠というのは、私たちの考えている、私たちがそこから通常は抜け出すことのできないこの世の時間とは別次元にある。 聖書で約束されている「永遠のいのち」は、そういう永遠について語っているのではないかと思うのです。
ということを考えてみて、 ふと、私のことだから以前にも似たようなことを書いていそうな気がして、 検索してみる。
自分で年始の恒例行事としている「GnuPGの公開鍵更新」を行いました。 といっても、GnuPGをそれほど日常的に使っているわけではありませんけれど。 作業にあたっては、 一年前の自分の日記を参考にしました。
ユニセフのベラミー事務局長は、スマトラ島沖の地震に対して 「全ての救援活動は、最初から子どもを視野に入れておかなければならないと信じる」 として、 (1)医療ケア、 (2)保護者と離れた子供のケア、 (3)子供を搾取から守ること、 (4)子供たちを早く学校に戻すこと、 などを挙げている。
これは第4報で読んだことだが、子供にとっての「学校」は「日常」であり、 被災という異常事態から子供の心を守るためには、その日常が重要な役割を果たすらしい。
どこで読んだかは忘れたけれど、 自分の親が波に飲まれて流されていく様子を目の前で見てしまった子供たちもいるそうだ。 そのような子供たちは激しいショックを受け、中には「どうして自分も一緒に流されなかったのか」などと思い悩む子もいるとのこと。
現在、苦しみの中にいる多くの人のために、また復旧活動などに力を注いでいる方々のために、 心から祈りたいと思います。
年末年始のお休みで送られてきていたレビューアさんからのコメントを整理する。 いつもありがとうございます。この内容は、初校の校正の際に反映する予定。 また、レビューアさんからの感想部分を元にして「読者の声」の準備も進める。
現在hyuki.comの中のCGIで、気になっているところをメモ。
今年の目標、というようなものは特にはありません。 でも、ぼんやりと心に描いているものはいくつかあります。 思いつくまま書いてみようと思います。
まず、サイト活動はシンプルにいきたいと思っています。 サイトの中でも、放置状態になっているものを少し整理し、更新すべきところには手をいれ、形を整えたいと思っています。 その流れで、公開しているCGIもいくつか整理しようと思っています。 今年は、このサイトを始めてから10年目ですので、再出発の年かも、と思ったりもします。
それから、ネット外の学びを大切にしようと思っています。 具体的に言うなら、Webページを読む時間よりも、 きちんと本を読みじっくり考える時間をとりたいと思っています。 もちろん、さぼりがちな聖書を読む時間も、ちゃんと確保したいですね。
お仕事では、すでに脱稿している最新刊が春には出版されるはずです。 そのほかに新刊を1冊、今年中には出版したいと思っています。 Web関連での新しいお仕事もはじまります。
今年の私の年間聖句は、 私たちが神を愛したのではなく、神が私たちを愛し、私たちの罪のために、なだめの供え物としての御子を遣わされました。ここに愛があるのです。 （ヨハネの手紙第一 4:10） を選ばせていただきました。 この聖句は「愛の方向性について書いている」と言ってもいいですし、 「神と人間との関係について書いている」と言ってもいいでしょう。 人間（わたし）というのは、神さまに愛されている存在なのだ、 ということをもう一度ゆっくり考え、味わいたいと思っています。
みなさんは、新しい年の初めにあたり、どんなことを感じ・お考えになったでしょうか。
あけましておめでとうございます。本年もどうぞよろしくお願いいたします。
年末年始は家族みんなで私の実家に出かけておりました。 久しぶりにキーボードに触らず、ネットもしない日を過ごしました。
いろいろと心に残る体験があったのですが、 それについては、また後ほど。
追伸：
年末年始の中で、 人間関係で本当に心痛める経験をなさっている方々からメールをいただきました。 私には何もできませんが、心を込めてかみさまにお祈りしております。 どうぞ気持ちをしっかりと持ち、主に信頼しつつ歩んでください。 歩むべき時、留まるべき時、語るべき時、黙すべき時を主が教えてくださいますように。
あなたのご意見・感想をお送りください。 あなたの一言が大きなはげみとなりますので、どんなことでもどうぞ。