Leo's Chronicle

夕焼け

2011-12-22T16:26:00.001+09:00

＠柏キャンパス

今週のたなくじ

2011-12-06T10:44:00.001+09:00

最近上手く撮れない…。真っ白なくじだといいことがあるそうですが、微妙。

Androidから

2011-11-11T19:22:00.001+09:00

投稿のテスト。ちなみに写真は0655月曜恒例のたなくじ。

レイアウトを変更

2011-11-11T17:28:00.001+09:00

久々にブログ。はてなブログに招待してもらったのですが、使い慣れたBloggerの方が書きやすそうで戻ってきました。

振り返ると１年以上書いてなかったんですね。。。

オープンソースとフリーソフトウェアは何が違うのか

2010-01-09T15:46:00.016+09:00

「オープンソース」と「フリーソフトウェア」。この二つは似ているようで決定的に違う。

「オープンソース」は言葉として「ソースが見られる」というただ一つの意味しか持ち得ないが、「フリーソフトウェア」はプログラムを使う人の「自由」を求める言葉だ。

Communications of ACMにRichard Stallmanが「オープンソースではだめなんだ」と訴える記事を書いている。ここで言う「フリー」とは、「無料（タダ）」という意味では決してない。ソフトウェアを使う自由、コードについて学び、変更する自由、そして変更の有無に関わらずソフトウェアのコピーを配布する自由のことだ。

1983年から始まったフリーソフトウェアを啓蒙する運動のおかげで、GNUのツール群や現在のLinuxがあり、これなしには今のGoogleの姿もなかっただろう。自由に使えるOS無しには大規模クラスタの運用などとても叶わないし、検索エンジンなどを通してGoogleが世の中に与えている社会的価値はとてつもなく大きい。「フリーソフトウェア」が目指すのはそういった「社会的な価値」の向上だ。オープンソース開発では、ソースを公開することで広くユーザー・開発者を集めソフトウェアの品質向上につなげているが、必ずしもそれが「フリーソフトウェア」の目標というわけではない。（なぜならオープンソースでなくても、品質の良い製品を作って売り続けている会社があることは皆様もよく知っているはずだ）

僕も勘違いしていたのだが、GNU Public License (GPL)を使うのが「フリーソフトウェア」というのも誤解である。GPLとは「ソフトウェアを使う、ソースコードを見る、改変する、再配布する自由」を保証するライセンスで、GPLでライセンスされたソフトウェアを使ったコードは必ずGPLでライセンスしなくてはいけないという制限を課している。企業ではこの強い制限を嫌って、より制約の緩いオープンソースライセンスであるBSDやApache Licenseなどを使うこともある。しかし、GPLはあくまで「フリーソフトウェア」の概念を普及するための手段であって、他のオープンソースライセンスを使っていても「フリーソフトウェア」とみなすことはできる。

「フリーソフトウェア」の敵はあくまで「使う人の自由を制限する独占的なソフトウェア」だ。いくらオープンソースであっても、DRM（メディアのコピーを制限するプログラム）のようなものは、使う人の自由を制限するので決して「フリーソフトウェア」にはなりえない。

「フリーソフトウェア」が目指すものはいわば「表現の自由 (free speech)」であって、決して作ったものを「無料（タダ）でよこせ(free beer)」と要求することではない。確かに現実問題として「Eric Sink on the Business of Software」にもあるように、ソースを公開してビジネスを成立させるのは、不可能ではないものの、非常に難しくなる。しかしながら、作ったプログラムを独占して目先の利益を追求することは、より長い目で見るともっと大きな社会的価値を逃しているのかもしれない。

今まで「フリーソフトウェア」運動は、単にMicrosoftのような企業に反抗するためだけのものかと思っていたが、今回のStallmanの記事を読んで随分印象が変わった。「自由」であることの価値を認めるならば、「オープンソース」と言う代わりに「フリーソフトウェア」という言葉を使うことで、より正確な意思表示ができるように思う。

EU基準から見ても多すぎる日本の債務残高

2010-01-03T14:15:00.022+09:00

大前研一氏の「「知の衰退」からいかに脱出するか?」によると、日本の財政赤字はEUに加盟しようとしても即座に断られるほどだそうだ。どういうことか気になって調べてみると、EU加盟の経済収斂基準というのがあり、そこに

財政：過剰財政赤字状態でないこと。
（財政赤字GDP比3％以下、債務残高GDP比60％以下）

と書かれている。財政支出、債務残高のGDP比を見ると、2008年の日本の財政赤字はGDP比の2.6％で、債務残高はGDP比の170％にもなっている。（wikipedia: 国内総生産 GDP)

2009年度の日本の実質GDPが520兆円規模なので、その3%は15.6兆円。これが国債を発行してよい基準額のはずだが、2010年度予算で44兆円国債を発行するようなので、GDP比の8.4%ということになり、EU基準を大幅に上回ってしまう。

財務省による2009年度の各国の債務残高のデータを見ると、日本の債務残高のGDP比が170%から189％に悪化しており、EU基準の債務残高のGDP比60％以内どころか、他国に比べても圧倒的に悪い水準だ。EUに相手にされないというのも頷ける。

「日本の対外債務は? 世界の対外債務国ワースト20をグラフ化してみる」という記事を見かけたが、これを見る限りは日本の債務残高は大したことのない額のようにみえる。しかし、このデータは上に挙げた財務省のデータと大きく食い違いおかしいと思っていた。このデータによると、イギリスの対外債務のGDP比が408.3%ということで、EU基準と大きく外れていてEUに残っていられるはずがない。財務省のデータの方では、イギリスの債務は2008年の57％から2009年の75.3%になっているので、最近になってEU加盟国として危ない状況になったとわかる。（参考までにWikipedia: EU加盟国の債務状況)

何も上記の「対外債務国ワースト２０」の記事のデータが間違っているわけではない。この元になったWorld Bankによる各国の対外債務のデータがこちらにある。そして、ここで使われている対外債務（External debt)の定義がこちらのPDFで読める。結局比べているものが違うのだ。債務残高として「日本の国債(bond)」と「海外諸国の対外債務(External debt)」という、そもそもの定義が違うものの値を比べることに大した意味はないし、日本の債務の深刻さから目を背けさせるという意味で悪影響とすらいえる。（イギリスもアメリカも国外からお金を借りまくっているという認識は間違いではないが）

日本の抱えている負債には、年金の支払い義務と、公的債務（地方債・国債）の２つがあり、年金債務は800兆円、公的債務も800兆円になると言われている。日本国民の金融資産1500兆円を考慮しても、借金はすでに返済不可能な状態になっている。なぜこの状態が放置されてきたのか？政府は借金を返さなくてもいいと思っているし、まともに年金を払おうとしてもすでに払えない。だからできるだけこの問題から目を背けようとさせている。例えば「改革」のため、あるいは「生活」のため。よく耳にしたお題目ではないだろうか。政権が代わっても、問題の本質を深く考えさせない政治のありかたは大して変わっていない。大前氏に言わせれば、

政府側の（短期間で配置換えさせられ責任も問われない）官僚機構だけが得をして、国民がかぎりなく損をするという構造になっている。

ということだ。

今回挙げたデータは、インターネットで検索すればすぐ見つかるようなものばかりだが、「なんだ、日本はまだ大丈夫なんだ」と安心させて「思考停止」に導くような情報には注意してほしい。ゼロベースで予算を見直すという民主党のマニフェストも、うやむやのままにさせてはいけない。研究者も仕分けされた一部の科学予算が復活したからといって安心していてはいけない。「考える力」を失うことのダメージは自分たちに直接返ってくる。

大前氏のテキストは考える力を養うための役に立ってくれるし、そしてドラッカーなどの著作もそうだが、著者の「考え」そのものを学ぶのではなく、「考え方」を学ぶために読むべきで、そうして自ら「考える力」をもった人が育つことが何よりも大切に思う。（身近なところでトレーニングを始めるなら、区議・市議会の議事録を眺めてみるとよい。大きな方針もなく些細な議論、とんでもない議論に始終しているかわかるはずだ。例えば、千葉の県議会の議事録で選択的夫婦別姓に関する意見を見ると、こんなロジックが破たんした議論を堂々と言える場所なのかと寒気がした。考えなしに議員に政治を任せているとこんな恐ろしい議論がまかり通ってしまう）

理系のためのサバイバル英語入門

2009-12-06T09:56:00.006+09:00

ふと本棚を眺めていると、「理系のためのサバイバル英語入門―勝ち抜くための科学英語上達法 (ブルーバックス)」という本を発見。東京大学の1～2年生向けに教養学部で開かれていたゼミ「理系のためのサバイバル英語入門」の内容を本にしたものです。もう10年以上前に書かれたものですが、まったく色褪せていないことに驚くばかり。

一番驚いたのが、昔読んだときと今読んだときとで印象がまったく異なっていること。この本の内容を十分に咀嚼するには、読む側にもレベルアップが必要なようです。

１．まず冒頭の科学用語の英語表現をどれだけ知っているかのテストで、高校や大学で学ぶ、文学・哲学・社会学中心の英語が、理系の学問では役に立たないことに気付きます。（大学1年生の頃、初めてこの本を読んだ僕はこのレベルでした。英語そのものを教える人ってどうしてもいわゆる理系分野を知らない人になることが多いので…）

２．自然な英語を書くとはどういうことか（英語で論文を書くようになった今は、ここで説明されていることがよくわかる）

３．英語でコミュニケーションをとること。（学会などのプレゼンテーションで英語のトークをするようになったので、うなずけることがたくさん）

辞書の使い方、簡潔な英語の書き方なども参考になりますが、巻末の永久保存版「論文を書くための論文」もお勧め。ここには、科学の分野で認めてもらうためには、メディアで名声を得るのではなく、「良い論文」を書かねばならないと断言されています。科学の世界ってそういうものなので、テレビで紹介されている部分だけでは決してわからない。

本書のいたるところに、研究の面白みや、独創的な研究をしていくためのエッセンスがちりばめられています。タイトルを「英語入門」とするには惜しい内容で、「科学への入門」「研究者入門」と呼ぶ方がふさわしいです。そこに気付かずに、理系英語の入門書としてだけとらえると相当にもったいない。けれども、読む側としても「科学」や「研究者」の世界に一歩足を踏み入れてないと、大学入学当初の僕のように、この本に書かれた大切なメッセージを受け取り損ねてしまいます。

これは「科学」の世界へ入っていくための「英語」入門書です。

ノーベル平和賞は誰がとるべきだったのか？

2009-10-10T17:57:00.022+09:00

今年のノーベル平和賞の受賞者(Nobel Laureate)がBarack Obama大統領に決まりましたが、「え!？」という声が多かったように思います。

僕も驚いた一人ですが、では他の候補は誰だったのでしょうか？ Economist誌での予測が紹介されていましたが、悲しいことに僕にはどんなことをした人たちなのかさっぱりわかりませんでした…。日本のニュースを見てるかぎりMichael Jacksonでもいいような気がしてきます。この中では間違いなく彼のニュースが一番多かったはずですから（苦笑）世界共通言語のEsperantoとかもいい線をついています。

僕がいかに世界の情勢をとらえていないかを実感したのですが（もちろん上のリストの大半の人はネタですよ。皆様。人じゃないのも含まれてますが）、一番右下の御仁が今回の受賞の立役者になったのは間違いないでしょう。

参考

2009 Nobel Peace Prize - Wikipedia （すごくよくまとまっています。受賞理由や各国の反応、他の候補者が全部で205人いたなど、ニュースを読むより効率良く情報が得られます）

Obama氏受賞に関しての記事

Not their best pick （反対意見）
...nor their worst pick（賛成意見）
Even greater expectations （Obama氏の受賞に関する総括記事）

東京大学理学部情報科学科のパンフレットがすごい

2009-10-08T21:51:00.007+09:00

先日の「ぜひ押さえておきたいコンピューターサイエンスの教科書」というエントリでは、東京大学理学部情報科学科の講義で使われていた教科書を中心に紹介しました。では、実際の授業の様子はどうなのでしょうか？

タイミングの良いことに、情報科学科のカリキュラムのパンフレットがウェブで公開されています。

東京大学理学部情報科学科パンフレット

かなりの力作で感動しました。なにせ今まで外向けの色気があまりにない学科だったので。。。（苦笑）

理学部情報科学科と工学系の学科との一番の違いは、パンフレットにもありますが、コンピューターの原理や理論的背景も押さえ（ここが重要）かつ最先端の技術やモノも作り上げていくところでしょうか。そんな雰囲気を、カリキュラムや実際の講義・演習の様子、教授陣のメッセージなどから、感じ取ってもらえることと思います。

一点だけ補足。このパンフレットには普通の学科紹介でよく見かける卒業生の就職状況の話がさらっとしか書かれていません。というのも、９割近くの人が大学院の修士課程（情報理工学系研究科コンピュータ科学専攻）に進学するのですが、僕の観測範囲内で、ここを出て就職先に困ったという人に出会ったことがありません。修士１年でまったく就活してなくても、修士２年の９月頃に内定が決まる強者とか。巷の就職苦労話と比べると相当浮世離れしている感じです。これは諸先輩方の功績の賜物なのでしょう（パンフレットにも第一線で活躍されている卒業生の方々が紹介されています）

ぜひ押さえておきたいコンピューターサイエンスの教科書

2009-09-21T19:07:00.068+09:00

僕はバイオインフォマティクスという生物と情報の融合分野で研究を行っています。東大の理学部情報科学科にいた頃は同僚のマニアックな知識に驚かされたものですが、そのような計算機専門の世界から一歩外に出ると、それが非常に希有な環境だったことに気が付きました。外の世界では、メモリとディスクの違いから、オートマトン、計算量の概念など、コンピューターサイエンスの基礎知識はあまり知られていませんでした。コンピューターサイエンスを学び始めたばかりの生物系の人と話をしているうちに、僕が学部時代に受けた教育のうち、彼らに欠けている知識についても具体的にわかるようになってきました。

バイオインフォマティクスに限らず、今後コンピュータを専門としていない人がコンピューターサイエンスについて学ぶ機会はますます多くなると思われます。そこで、これからコンピューターサイエンスを学ぼうとする人の手助けとなるように、基礎となる参考書をまとめることにしました。

ここで紹介する本は主に英語のものですが、初学者でも読みやすいように配慮されているもの選びました。ただし、ここに挙げた書籍を合わせると、生物学系の定番教科書「Molecular Biology of the Cell」(1392ページ！)よりも分量がはるかに多く、ただ情報を吸収するだけではなく、自ら頭や手を動かして能動的に考えないと理解できないため壁も高めです。挫折しないためには、一度きちんと勉強した研究者のガイドを受けながら読むか、大学の情報系の講義に参加して科目の全体像、重要なポイントを知った上で読むことを「強く」お勧めします。もちろん、自力で読みこなせればそれに越したことはありませんのでぜひ頑張ってみてください。

この分野にこれから入ってこようとしている人をdiscourageさせないようにあらかじめ断っておくと、実はここに紹介してある本の内容を完全に理解していなくても実用上はさほど困らないかと思われます。東大の理学部情報科学科でも、教科書を全部読むような教え方ではなく、本の中の重要なエッセンスを取り出したレジュメをもとに講義が行われています。このように分野の雰囲気、全体像を知ることは大切です。というのも、本当に困るのは、必要なときにどこに必要な知識があるかわからなかったり、目の前の問題を解決するためにどのような考え方をすべきかを知らない場合だからです。僕自身の経験でも、大学の講義を受けているときにはちっとも身が入らずほとんど理解していなかったことが、数年後、キーワードを知っていたおかげで、本を通して読まずとも読むべき場所がわかり、内容がすいすい頭に入ってくることが多々ありました。授業のありがたみはこんなときに実感できます。

まずはOSからコンピューターサイエンスは、理論的なものから実用に近いものまでとても応用範囲の幅広い分野です。その基礎として、まず第一にデータ構造やアルゴリズムの知識をまず学ぶべきだと思っていたのですが、それよりも先に、コンピュータを動かしているOSそのものの知識が必要だったのです。情報屋さんは日頃OSに慣れ親しんでいるので、ここが情報系以外の人に理解されていないのが盲点でした。例えば、コンピューター上でプログラムがどう実行されるのか？１つしかないCPUで、複数のアプリケーションがどうして同時に動いているように見えるのか？（プロセス、スレッド、CPUスケジューリング）、データがメモリやファイルにどのように保存されているか。システムコールとは何か。オペレーティングシステムについて学ぶには、Silberschatz先生による「 Operating System Concepts」が定番で俗に恐竜本とも呼ばれています。アルゴリズムを学ぶ前に、それを動かす大前提となるシステムがどのように動き、どのような性質をもっているのか。情報科学科では、実際にプロセスやスレッドを生成してシェルを実装してみたり、ファイルの読み書きなどを演習しながら、これらの知識を身につけていきます。

計算の理論計算の数学的な性質について学ぶことは、計算できるものと、できないものの違いを知るために必要です。また、どのくらいの速さ、メモリ量で計算できるか？それらがどのような計算の仕方で計算できる問題なのか？について学びます。具体的にはオートマトン、正規表現、文脈自由文法、チューリングマシン、計算の複雑さ(computational complexity, NP完全問題など)、判定可能性（アルゴリズムの限界、アルゴリズムで解けない問題というのがある）などが含まれます。MITの屈指の名講義と呼ばれるSipser先生の講義を教科書にした「Introduction to the Theory of Computation」がとても読みやすいのでお勧めです。この本に限っては、日本語訳版も対応の英語付きで丁寧に訳されているので日英での用語の違いに戸惑うこともないでしょう。（注：上記のリンクは初版の日本語訳に張ってありますが、第二版の日本語訳も内容を３冊に分けて出版されています。）計算のクラスを考える必要がある例を挙げると、例えば、正規表現の限界（参考：Leo's Chronicle 「正規表現に見切りをつけるとき」)を考える理由がよくわからなかった場合は、この本の内容が参考になります。

計算理論に関しては、Garey and Johnson本「Computers and Intractability: A Guide to the Theory of Np-Completeness (Series of Books in the Mathematical Sciences)」も定番中の定番です。読みやすく（易しいという意味ではなく、簡潔という意味です）、NP完全であることの証明パターンや、そのための巻末のNP完全問題のリストが役に立ちます。この本の「Coping with NP-Complete Problems（難しい問題といかに付き合っていくか）」という章のタイトルは非常に有名で、コンピューターサイエンスという学問を如実に表している表現です。

データ構造とアルゴリズム離散数学とも呼ばれるこの分野。日本語で平易に書かれた教科書もあるのですが（例えば、データ構造とアルゴリズム (新・情報通信システム工学)や、計算とアルゴリズム (新コンピュータサイエンス講座)など）、やはり、list、hash、red-black tree, ネットワークフロー、グラフ、木構造など主要なデータ構造をカバーしつつ、NP完全性や集合論などの数学的な基礎知識も巻末に儲けられている「Introduction to Algorithms, Third Edition」が便利です。今月には第３版も出るようです。ただし、内容が豊富で記述も多いため、初学者が通して読む目的には向かない本だとは思います。上に挙げたデータ構造について学んだあと、一通りの手法（Greedy（貪欲）アルゴリズム、分割統治法、Dynamic Programming(DP)、近似、Randomizedアルゴリズムなど）を身につけたい場合は、「Algorithm Design」の方が講義用に構成されている分読みやすいかと思います。

連続系アルゴリズム工学的には、離散値だけではなく、実数データを扱ったり、固有値問題や、偏微分方程式をCG法(共役勾配法）で解く、波形データの解析のために高速フーリエ変換(FFT)を使う、統計量の計算、検定など、計算機が活躍する場面が多々存在します。これらの計算は並列化して高速に計算する需要も大きく、そのような連続系の計算を理解するのに役立つのが「Numerical Recipes 3rd Edition: The Art of Scientific Computing」です。計算を手法とソースコードの双方向から学習できるので、演習向けです。大学の線形代数の内容も、ここにあるような実際の計算までやってみるともっと楽しくなるように思います。最新版ではSVM（Support Vector Machine）やHMM(Hidden Marcov Model)まで言及されているとか。

ハードウェアレジスタとは何か知っていますか？マシン語は？計算機の中で整数や小数点以下の数はどう表現されているの？などなど、JavaやRubyなど現代の便利なプログラミング言語しか使っていないと見えなくなってしまうハードウェアの世界を学ぶためには「コンピュータの構成と設計~ハードウエアとソフトウエアのインタフェース第3版 (上), (下)」が良いでしょう。（注：通称パタヘネ本です。ヘネパタはまた別の本のことです）計算機科学はハードウェアとともに進化してきました。最新のCPUの内部構成を理解するには、レジスタ、計算のパイプライン化、割り込み、キャッシュなどの知識が不可欠ですし、これらを学べる本も、他には見当たらなくなってきました。同じメモリアクセスでもキャッシュに載っている場合とそうでない場合（localityの有無）で相当の性能差があるので、CPUの中身でどのように演算が行われているかを知らないと、CPUの性能を最大限引き出したプログラムは決して書けません。一度は目を通しておくべき本だと思います。

情報論理アルゴリズムを設計したとき、それが正しい結果を出すこと(soundness)、そしてそのアルゴリズムがすべての答えを見つけ出すこと(completeness)を検証します。このようなsoundness/completenessの概念や、述語論理でロジックの等価性を証明したり、逆に背理法などで矛盾を導きだす技術もどこかで学ぶべきだと思います。萩谷先生の情報論理の講義資料が手軽に学べて良いと思っていますが、まとまった英語の教科書があればぜひ教えてください（識者の方）

プログラミング言語　といってもC++やJavaなどの言語の仕様のことではなく、λ計算、型情報などを用いてプログラムやその意味を数学的に表記する（操作的意味論を用いる）ことで、言語の仕様を正確に定義するのに使えたり、プログラムの意味を変えずに最適化（等価変換）する、また、プログラムが安全に実行されるかどうかを検証できるようにもなります。Pierce先生の書いたTypes and Programming Languages（TAPL）が非常にわかりやすく必要な知識がまとめられた本だと思います。

蛇足ですが、近年日本のインターネット界隈でSICPがプログラミング言語を理論的に学ぶ本として話題になっているのですが、コメント欄で住井先生が指摘されているように、SICPとTAPLではカバーしている世界が違います。僕自身も、この本をベースにした演習をしたり、最後の章にあるようなSchemeでSchemeコンパイラまで作った経験から、SICPだけで関数型言語の勉強をした気になってしまうと視野が狭くなるように思います。関数型言語に慣れたり内部の仕組みを知るにはSICP、操作意味論や型について学ぶにはTAPLが良いでしょう。

(注：このプログラミング言語に関する部分は僕の説明や用語の使い方が悪い書き方になっていたため、住井先生の指摘を受けて書き直しました。そのため、下の方にある住井先生のコメントが指していた内容がわからなくなってしまいました。すみません。）

コンパイラテキストデータを解析するには書かせない技術です。字句解析、構文解析に始まり、構文木から実行したいコードを作成。コード内で変数の生存範囲を見て最適化を施すなどなど。プログラミング言語を作る以外にも、独自データを表現しやすくするためのデータフォーマットを作ったり、ミニ言語を作って日頃の作業を効率化するなり、身につけると非常に強力な武器になります。Compilers: Principles, Techniques, and Tools (2nd Edition)、通称Dragon Bookが一応教科書的なポジションを占めているのですが、最初から読むと構文解析すらできないうちに挫折する可能性が高いので注意。おすすめの読み方は、実際に使うツールに合わせて読むこと。例えば、ANTLRを使うならLL(1)文法を、Lex/Yacc（Flex/Bison）を使うならLALR(1)文法を知らないとデバッグすらままならないので、必要に迫られて本の該当箇所を読む使い方が良いように思います。てっとり早く内容を把握するには、萩谷先生のコンパイラの講義資料を参考に。簡潔にまとまっていて、本を読み解くのに役立ちます。

データベースシステム Webやユーザーからデータを集めて管理、表示するWebアプリケーションでは、データベースの存在が必要不可欠になってきました。バイオインフォマティクスでは、毎日テラバイト規模のデータを扱う技術が必要になってきています。データベースに関する教科書は、以前 Leo's Chronicle:ぜひ押さえておきたいデータベースの教科書で紹介しました。Raghu本 Database Management Systemsがお勧め。ストレージ管理、データベースの同時更新をさばくためのトランザクション管理、これらの技術は年々重要度を増してきていますし、Google File Systemに代表される分散ストレージや、SSDの登場による時代の変化などに対応していくためにも、データベースシステムの仕組みはぜひ押さえておきたい知識です。

ここに紹介した他にも、コンピューターグラフィックス、自然言語処理、機械学習、データマイニング、ウェブ情報処理、ゲノム配列用の文字列検索、索引、圧縮データ構造、Information Retrieval (IR)など、ここでは紹介しきれないほど、コンピューターサイエンスの応用は多岐に渡っています。そして、教科書にある知識を身につけることも大切ですが、より大事なのは、それらを活用して、コンピューターの力を応用できる分野を切り開いていくことだと思います。

（このエントリを書いているうちに、自分の知識の浅さや分野の広さにくらくらしてきました。他にもコンピューターサイエンスの基礎として勉強すべき分野、良い教科書があるよ、という情報を教えていただけると幸いです）

関連

東京大学理学部情報科学科のカリキュラム（このカリキュラムの２〜３年次の内容はカバーしたいと思ったのですが、これだけ並べてもまだ覆いきれてない気がします…）

OMakeで快適に論文執筆：TeX編

2009-09-17T16:30:00.018+09:00

Windows上でTeXの論文を快適に書くためのTipsを紹介。インストールが必要なものは以下の通り：

OMake：ファイルの更新をモニターして自動再ビルドしてくれる優れもの
TeX一式：僕は英語論文しか書かないのでMikTeXを使っています。インストールが簡単
pdfopen, pdfclose: Acrobat Reader でPDFファイルを開け閉しめするのに使います（MikTexにも同梱されていますが、back機能が使えるこちらの方が便利。参考：http://magic.aladdin.cs.cmu.edu/2005/07/15/pdfopen-and-pdfclose/)

omakeと、pdflatex, pdfopen, pdfcloseがコマンドライン（コマンドプロンプトやCygwinシェル）から使えるように、環境変数PATHを設定します。

以下は僕の使っているCygwin用の.bash_profileや.zprofileの設定例です：

export MIKTEX_BIN="/cygdrive/c/Program Files/MiKTeX 2.8/miktex/bin"
export OMAKE_BIN="/cygdrive/c/Program Files/OMake/bin"
export PATH=$OMAKE_BIN:$MIKTEX_BIN:$PATH

論文のファイルが以下のように配置されていると仮定します：

project/paper.tex
project/paper.bib

準備として、omake --installで、OMakefile、OMakerootファイルを作成します。

project> omake --install

次に、OMakefileの内容を以下のように編集します。通常はtex -> dvi -> pdf という流れを辿るのですが、より快適に作業するために、pdflatexを使ってtexファイルから直接PDFを生成するように設定しています。

.PHONY: all install clean preview

USEPDFLATEX=true
PREFIX=paper

PREVIEW_PDF=$(PREFIX)-preview.pdf

LaTeXDocument($(PREFIX), $(PREFIX))

$(PREFIX).pdf: $(PREFIX).bib

preview: $(PREFIX).pdf
 pdfclose --file $(PREVIEW_PDF) || true
 cp $(PREFIX).pdf $(PREVIEW_PDF)
 pdfopen --file $(PREVIEW_PDF) --back

.DEFAULT: preview

（注： cygwinを使わない場合は、上記のcpコマンドを、copyに置き換えるとよいです）

omakeを起動します。

project> omake -P

-Pオプションは、texやbibファイルをモニターして、更新があれば即座に再ビルドしてくれるという機能。AcrobatはPDFファイルを開くとロックしてしまいPDFファイルの上書き更新ができなくなってしまうのですが、pdfclose, pdfopenを使うことで、その問題も解決しています。快適。

関連

Leo's Chronicle: [TeX] 論文執筆のサイクル短縮

世界のトップ研究者がデータベースの未来を語る - Claremont Report on Database Research

2009-09-11T23:45:00.009+09:00

５年に一度、データベースのトップ研究者が一か所に集まって、データベースの未来について語るThe Clearemont Report on Database Research 2008の記事がCACMに紹介されていました。

The Claremont Report on Database Research
（各研究者のプレゼンテーションスライドはこちらから）

大規模データ処理、RDBMSエンジンの見直しの必要性、クラウド、MapReduce、開発者にとってのデータベースの使いやすさ、新しい言語は？、Uncertain data, プライバシーの管理などなど、DBの将来を見据えた意見が盛りだくさんです。

どの研究者がどの方向性を打ち出しているのかを記事から読み取れれば、もう立派なデータベース通。そして、錚々たるメンバーのなかになぜかTim O'Reillyが混じっている。。。

とにもかくにも、彼らがこうだというと、間違いなくデータベース研究の世界はこの方向に動いていくので要注目です。

研究者の仕事術 - 「いかに働き、いかに生きるか」

2009-09-10T09:31:00.020+09:00

「いかに働き、いかに生きるか」

やるべきことが見えてくる研究者の仕事術―プロフェッショナル根性論

最初は「研究者」のための本かと思って購入したのですが、そんなことはありませんでした。会社や組織に縛られて不自由な思いをしていたとしても、自分の人生にとって大切なことはしっかりものにするためのエッセンスが見事に凝縮されています。

研究者として仕事をすべき１０の原則
「興味を持てる得意分野を発見する」
「最初は自分で学ぶ」
「師匠を持つ」
「現場で恥をかく」
「失敗を恐れつつも、果敢に挑戦する」
「自分の世界で一番になり成功体験を得る」
「研究者としての自信をつける」
「井の中の蛙であったことに気付き、打ちのめされる」
「すべてを知ることはできないことを理解する」
「それでも、自分の新しい見識を常に世に問うていく」

一見当たり前のようでも、自らが紆余曲折を経てこの原則に辿りつくことの大切さは、研究者として共感できるところが多いです。この本のタイトルが、「研究者のための仕事術」ではなく「研究者の仕事術」となっているように、研究者の仕事の仕方を垣間見ることで、研究者以外の人にもぜひ知ってほしい考え方が詰まっています。

ネットでアメリカの有名大学の講義が視聴できるようになった今、なぜ大学や、PhDが必要なのか？こんな素朴な疑問への答えもここにあります。スキルを身につけるための設備を提供するインフラという意味もありますが、もっと大切なことは「人間的成長」の機会を与える場としての大学の役割です。サーチエンジンの力で目的の知識に辿りつくためのパスは短くなったとしても、この本にあるような、自身の「人間的成長」は、段階を踏んでひとつひとつ登っていかなければなりません。

山積みになるタスク、環境の変化に対する恐れをどう克服するか。自己表現のためのプレゼンテーション力や英語力とは何か。このエントリも、本書のブログをいかに書くかという意見に触発されて書いています。

恐らく島岡先生自身の、Cell, Nature, ScienceにPI(Principal Investigator：主任研究者)としてFirst Authorの論文を一本、指導者としてLast Authorで一本という「成功体験」があるからこそ書ける本ですが、その業績に奢ることなく、不安と闘いながらも「一番」を目指して常に勝負し続けている姿がうかがえます。僕自身も、勝負に出ようとしていたり、壁にぶちあたったり、といろいろあるのですが、この本のメッセージがとても励みになっていて、良いタイミングで読めたことに感謝しています。

最初178ページで2,940円という設定に驚きましたが、内容をみると至極納得。このテーマの自己啓発本としては、本当に大事なことが集約されている一冊です。

関連

民主党マニフェストのテストコード

2009-08-31T11:35:00.017+09:00

プログラミングの世界ではコードの動作を確認するために「テストコード」を書きます。仕様の変更などでコードを大幅に修正する機会は多いのですが、テストコードがあれば重要な機能が動かなくなった場合でも、すぐに確認できます。政治の世界でも、マニフェストの実現度合いを確認するための「テストコード」が必要ではないでしょうか。

テストコードを動かしてみると以下のようになります。今はマニフェストの実装（実現）段階なので、もちろん真っ赤（すべて動いていない状態）です。

テストをすべてパスすると、表示は緑になるはずです。

このようなテストコードがあると、政治の解釈、問題点がゆがめられていないかを、その都度確認していくことができます。一票を投じることも大切ですが、一般に分かりやすい部分しか報道しないマスコミに頼らず、各々が持つ専門的な知識（育児、教育、研究、経済などなど）を活用して、自らの目で政治が行われる様を監視していくことが大事だと思います。

このブログを読んでくれている皆さまも、自分が政治に期待するものを「テストコード」の形でメモしていってはいかがでしょうか？

ソースコードはこちら：


import static org.junit.Assert.*;
import org.junit.Test;

public class ManifestoTest
{
  @Test
  public void 子ども手当・出産支援() {
    fail("保育所の確保など、職を失わずに子育てできるようにはなってない");
  }

  @Test
  public void 公立高校の無償化() {
    fail("本当は大学まで親の所得に関わらず通える仕組みが必要");
  }

  @Test
  public void 年金制度改革() {
    fail("無責任がまかり通った原因と責任の追求、再発防止の仕組みが必要");
  }

  @Test
  public void 医療・介護の再生() {
    fail("過剰労働・安給料で勤務医や介護を担うのは無理です");
  }

  @Test
  public void 農業の個別所得保障() {
    fail("国内農家を優遇して、国外の安くて安全な食べ物を輸入できなくなると、消費者にとってはマイナス");
  }

  @Test
  public void 暫定税率の廃止() {
    fail("省庁の聖域である特別会計に本当にメスを入れてくれるのか？");
  }

  @Test
  public void 高速道路の無料化() {
    fail("報道ステーションでは、民主よりの無料化提唱者より、猪瀬氏の方がまともだった。。。");
  }

  // 個人的な願い
  @Test
  public void 選択的夫婦別姓() {
    fail("何年待たせるのか");
  }
}

（上のコードは適当に書いていますが、実は、この「テストコード」の中身をどう実装していくかも大きな問題）

関連

SSD投入でDBMSのココが変わる! - WEB+DB PRESS vol. 52

2009-08-19T13:14:00.008+09:00

SSDを使うとDBMSはどう変わる？徹底検証した記事を書きました！

WEB+DB PRESS Vol.52 予約受付中です。

実際に最新最速のSSD、Intel X25-Eを使ってDBMSのパフォーマンスを計測するなど、わくわくしながら記事を書くことができました。SSDの実力に驚きつつも、使い方を間違えるとHDDより遅くなる？など新しい発見もあり。

そして、SSDとHDDの違いがどのようにデータベースの性能に影響するのか？ディスク上のデータ構造（ヒープ、B+-treeなど）からバッファ管理など、データベースシステムの中身を解剖してわかりやすく解説しています。読みやすくなったのは丁寧に添削してくださった担当様のおかげです。感謝。

ディスクを活用したデータのソーティング（External merge sortなど）に加え、2009年6月にEdgar F. Codd Innovation Awardを受賞した喜連川先生のHash joinのアルゴリズムにもこれ以上ないタイミングで言及。MapReduceなんて、20年以上も前にDB屋さんがとっくに発明していて偉いんだ（？）などと、内容も盛りだくさんです。（最初8ページくらいの予定が、19ページ分にもなりました。。。）

SSDについてだけでなく、DBMSのチューニングを極めるなら、ぜひおさえておきたい知識が満載です。SSD時代になっても、B+-treeなどのDB技術は色褪せることなくまだまだ輝きつづけます。

乞うご期待。

関連記事

ゲノムひろば2009 in アキバ

2009-08-03T11:37:00.003+09:00

「ゲノムひろば2009 in アキバ」に家族で遊びに行ってきました。写真はたまねぎをすりおろしてゲノムを採取する実験の様子。きらきらの糸状のものがゲノム（の束）らしいです。肉眼で見えるくらいまとまるとは。すごいすごい。

美ら海水族館@銀座ソニービル

2009-08-03T11:22:00.003+09:00

先日、毎年恒例の「Sony Aquarium 沖縄美ら海（ちゅらうみ）水族館」（銀座ソニービル）に行ってきました。写真はトラフザメ。こんなにガラス際に寄られると、まるでこちらが観察されているようです。。。

あなたのやる気を引きだす３つのレンズ

2009-07-31T20:25:00.004+09:00

（昔、Harvard Business Reviewに乗っていた記事の引用。Manage Your Energy Instead of Time and Rejuvenate。仕事に対する見方をスイッチし、やる気をコントロールするのに便利。あとで訳します）

Emotional Energy

Defuse negative emotions— irritability, impatience, anxiety, insecurity— through deep abdominal breathing.
Fuel positive emotions in yourself and others by regularly expressing appreciation to others in detailed, specific terms through notes, emails, calls, or conversations
Look at upsetting situations through new lenses. For example ...

Adopt a “reverse lens” to ask, “What would the other person in this conflict say, and how might he be right?”
Use a “long lens” to ask, “How will I likely view this situation in six months?”
Employ a “wide lens” to ask, “How can I grow and learn from this situation?”

未来を予測する一番よい方法は、自ら未来を創ることだ

2009-07-30T13:27:00.020+09:00

石井先生の基調講演で紹介されていた言葉：

The best way to predict the future is to invent it.　- Alan Kay
(未来を予測する一番よい方法は、自ら未来を創ることだ）

Alan Kayは、今や常識となったオブジェクト指向プログラミング(1960-1970年代ごろ)や、ウィンドウを重ねるGUI、ノートブック型のコンピュータ(Dynabook, 1968)など、現在のパソコンの基となるアイデアを考案してきました。それらの功績から2003年にはACM Turing賞（いわば、Computer Scienceのノーベル賞）を受賞しています。

彼がこれらのアイデアを考案して40年後の今、僕の目の前にはウィンドウがあり、オブジェクト指向の考え方を使ってプログラムを書いています。彼の言葉は、まことにむべなるかなと思わざるをえません。

民主党マニフェストに選択的夫婦別姓が盛り込まれる？

2009-07-28T13:16:00.017+09:00

（以下の記事は民主党のマニフェストと、政策集INDEX2009を混同して書いたものです。まだこの２種類の扱いの違いが不明瞭なので、どう反応して良いか扱いに困っています。追記：結局、朝日の記事がいたずらに反感を煽っていただけなのが分かりました。最後にまとめてあります。）

7月15日の朝日新聞の記事にて、民主党が選択的夫婦別姓をマニフェスト、つまり公約に明記するのを見送る方針を決めたとの記事がありました。（ニュースサイトは数カ月したら記事を消してしまうので、引用しておきます）

民主党は、総選挙マニフェスト（政権公約）で、選択的夫婦別姓制度を柱とした民法改正の明記を見送る方針を決めた。...（中略）ある幹部は「これまでは野党だから（否決前提に）提出できた」と説明したという。政権政党となれば、実現をめぐって党内の推進、反対両派の対立が過熱しかねないとの懸念があるようだ。（民主公約、夫婦別姓明記見送り　党内に根強い慎重論 asahi.com)

この記事の内容に関してはてなブックマークのコメント欄では非難が飛び交っていました。10年以上にもわたって法案を提出していた姿勢は何だったのか？と。後日、朝日新聞の投書欄でも、この決定に失望したとの趣旨の意見がありました。しかし、先日発表されたマニフェスト（に伴う政策集INDEX)では、以下のようにしっかりと選択的夫婦別姓の導入が明記されています。

選択的夫婦別姓の早期実現

民法を改正し、選択的夫婦別姓等を導入します。

現在日本では、本人が希望しても夫婦別姓は認められておらず、婚姻した夫婦の96％で女性が改姓していますが、仕事上の事情から結婚前の姓を名乗り続けたい、生来の姓を自己のアイデンティティと感じるなどのさまざまな理由で夫婦別姓を望む人が選択できる制度を求める声が若い世代を中心に増えています。民主党がこれまで提出してきた民法改正案では、婚外子（非摘出子）の相続差別をなくすこと、再婚禁止期間を100日に短縮することも盛り込んでいます。 （2009年民主党政策集 INDEX 2009）

朝日の記事が巻き起こしたあの騒動はなんだったのか。この記事があったから「見送り」をやめたのか、そもそも記事がいい加減だったのか。もはや判断できなくなってしまいました。自分の目でマニフェストを確認しなければ、「民主は野党だから好き放題言ってこれた」という印象を拭えないままだったことでしょう。

記事の内容に反する結果となったにも関わらず、asahi.comの総選挙特集ページには今回の夫婦別姓の件をフォローする記事もなく、まるで自分たちが持ち上げた政策の話題などなかったかのように、諸手当や減税の話のみを取り上げています。

議論の対象をメディア任せにしていてはいけないことが、本当によくわかる例でした。

はてなを見ていると、hot ≠ valuable というのが良くわかる。転じて、政策の議論も、hot ≠ valuable だと感じる。議論の対象をメディア任せにしていてはいけない。Twitter / Taro L. Saito

いまの新聞は自らが紹介した記事の内容に関して、お世辞にも「真摯（しんし）」とは言えません。例えば、紹介した記事をウェブ上から削除してしまうため、自ら過去の記事を引用して振り返ることはありません。そのため、内容の真偽ともども、テーマに沿って議論を深める機能などが著しく欠けてしまいます。ただし、ここで必要なのは記事の訂正ではありません。『「正直」である前に「真摯」であれ』という記事で述べましたが、間違いを認めるとともに、自らが持ち上げた話題に関して言及を続ける姿勢こそが、今メディアに必要なものだと考えます。

（追記）

誤解の原因がわかりました。2007年の民主党のマニフェストを見ても、政策リストには「選択的夫婦別姓」が盛り込まれているものの、端的にまとめた政権公約であるマニフェストの方には、選択的夫婦別姓の話は入っていません。 2009年も同様です。これなら、プレゼンテーションの仕方が一貫しているので納得できます。

選択的夫婦別姓は、実際に不便を被っていないとその必要性が実感できない政策です。これを前面にだすと、おそらく大半の人にとって結婚したら夫の姓になるのが常識の今の日本では、いたずらに不安を助長するようなものです。木を見て森を見ずという言葉があるように、細事を先に説明してしまうと本質が見えにくくなるので、このような手法はプレゼンテーションではよく使われます。

そうすると、夫婦別姓の実現を待ち望む人たちの反感を煽る悪意があったのは、むしろ朝日新聞の記事ということになります。過去にもマニフェストに夫婦別姓が記載された事実はないのですから。そんな記事に踊らされた自分が悔しい。

新しいデスク

2009-06-30T18:30:00.010+09:00

職場の部屋とデスクを引っ越ししました。隣の部屋に移動するだけなのに、5時間もかかってしまい、今日の仕事はほとんど引っ越しだけで終了。

落ち着いて作業できるようになるまで、もう少し慣れが必要かも。

ウェブ時代に成果をあげるための心得

2009-06-25T17:01:00.031+09:00

ウェブ時代において、質の高い仕事をし、大きな成果をあげようとする人のための心得：

面白いからといってやみくもに読むのはやめなさい。ウェブでは、あなたが読むよりも速く情報が増殖していく

人の目を介して編集された質の高い文章を読むようにしなさい

人生は短い。多くの意見を聞くのではなく、少数の、物事を深く考えよく洗練された人と議論すること

（1996年にチューリング賞を受賞した、Amir Pnueliの言葉だそうです）

炭鉱のカナリア

2009-06-10T17:12:00.010+09:00

論文書きなどで論理を練る訓練をしていると、文章には、指す対象を「あいまい」にしたまま扱える「表現力の強さ」がある、と気付くようになりました。

論文ではあいまいな表現はすぐに潰しますが、ブログで書く文章では、対象を限定しすぎてしまわないように敢えて「あいまい」にしたり、意図的に、根拠などが「あいまい」な事柄をもとに「あいまい」なことを書いて、AでBになり、だからCという一直線のロジックだけではうまくとらえられないものを表現したりしています。なので、曖昧かどうかの区別は、おそらく普通の人より随分とはっきりしていて、読み手がどの部分に「あいまいさ」を感じて、ひっかかるかは、把握しているつもりです。

それゆえ、はてブなどで、他の人にとっては「あいまい」な表現だと気づかずに、自分の世界の中だけしか意味の通じない文章を、敵意むき出しで投げかけられると悲しくなります。なぜなら、そのような言葉を投げかける人にとっては何も「あいまい」ではないから。文章の意味は「あいまい」だけれど、敵意だけは伝わる。防ぐのが難しい強力な武器。

この様子を「炭鉱のカナリア」とは、よく言ったものだと思う。

「反響全部読み」は長い人生にはプラス(修行みたいなもの)。とくに創作者にとっては。ただし強烈な副作用(解毒に数年を要す)を覚悟する必要あり。炭坑のカナリアより

山形浩生氏のように、徹底的に「あいまい」な部分や、相手の至らなさを糾弾して、相手を打ち負かすというのも一つの手だとは思いますが、僕の場合は、そこでまともに「相手にする」ことで得られるものに期待できず、やられっぱなしになるばかりで疲れだけが溜まります。

これは、ある意味「相手に議論する価値を認めていない」失礼な態度なのですが、「文章が伝えるもの」を意識しないと良い循環が生まれない、「残念」に「残念」という禅問答の域を越えられない、僕が先のエントリで言葉にしたかったのは、まさにそういうことなんです。（これも「あいまい」な表現ですね）

「残念」に「残念」という禅問答

2009-06-10T16:47:00.011+09:00

「何が残念なのですか？」

梅田氏

「日本のWebは残念だ」

dankogai氏

「そういう梅田氏も残念だ」

楠氏

「やっぱり日本のWebは残念だと思うよ」

残念という意見ばかりで僕も残念です。さて、「残念」からうまく抜け出すにはどうしたらよいでしょうか？

梅田望夫氏の功績

2009-06-08T15:19:00.019+09:00

はてな界隈での騒動を眺めていると、彼は「大したことはしていない」という言説であったり、「がっかりだ」という趣旨の発言を非常に多く見かけます。

しかし、こと文章を書く力においては、そう批難する側の人たちの文章力は、彼の足もとにも及んでおらず、稚拙なものが目立つように思います。例えば、文章を印象付けるための工夫であったり、物事をわかりやすく伝える技術(指示語や議論の対象を明確にする配慮など）に欠けているため、厳しい言葉を投げかけるわりには、足元がしっかりしていないような印象を受けるのです。

そのような様子を見ていると、なんだかやるせない気持ちになります。はじめから「文体」を大事にしている人と、その機微には目もくれず、表面的な成果や発言の意味ばかりに気が向いてしまう人。そのように、メッセージの媒介である文体そのものを無視してしまうと、彼が世の中に示した一番大事な功績を見逃してしまうように思います。それは、Webの世界を分析したことでも、はてなに貢献していることでもないでしょう。

世の中で起こっていることを、文章で広く伝えるのに、その「書き方」がいかに大事であるか。

その「書き方」には「文体」のみにとどまらず、どのようなタイトルを付け、どのような読者を対象にしたメディア（書籍、ブログなど）を使うかも含まれると思います。彼の発言の趣旨を深く理解することにもある一定の面白さはありますが、彼の示した道を活用する術を見出し、実践していく方がはるかに楽しい世界が待っているように思います。

「Web進化論」が書かれた当時、「Web」や「Google」の話は、多くの人にとって「驚き」でした。そして、それが「驚き」であることに「驚いた」技術者の方も多かったのではないでしょうか。僕自身、研究者という仕事柄、何かの形（論文など）で文章になってはいるものの、書かれるべき場所や、文体がふさわしくなかったがために埋もれている「驚き」は多くあると感じています。

そう。彼のやり方が当てはめられる対象はなにも「Web」や「Google」の話に限らないのです。データベースシステムの研究が専門の僕なら、後で紹介しますが、一般の人向けの「データベースシステム入門」のような記事が書けるし、「世界史講義録」のような広く学校で教えられている事柄でも、敢えてWebで書くことで新たな価値が見出されます。

このような文章は知識だけあれば誰でも書ける類のものではありません。より広い知識と深い理解に裏打ちされた上で、伝えるべき情報を選択する必要があるし、ただ書くだけではなく、読者に合わせて文章を練る必要があります。「知見」を「いかに書くか」の大切さを、これほどまでに見せつけてくれた人は、梅田氏以外にはなかなかすぐには思いつきません。また、その「書く力」が一朝一夕で身についたものではないことを伝え聞いています。彼は「昔からよく文章を書いていた」と。

そして、彼と張り合うなら、「はてな」などを含む「Web」に対する見解を述べるだけではなく、その「Web」を使って自分自身が「何を」「どのように」伝えられるのかで競って欲しいと思うのです。

関連

Leo's Chronicle：データベースシステム入門：「データベースは体育会系図書館？」（専門用語はなるべく使ないように配慮し、使った場合、それがどういうものかイメージできるように説明してあります）
「世界史講義録」（高校での世界史の講義の内容を文章におこしたものですが、クラスルームで聞くしかできないのと、Web上にあるのとでは、世の中に与える影響が断然違います。学生にとっては「時間」を飛び越えて先読み、復習できる便利さがあるし、他の先生にとっても自身の授業に活かすことで、学生に良い授業を受ける機会が生まれ、とても良い循環が生まれます。）

研究者はどれくらい論文を読むのか？

2009-05-25T13:18:00.015+09:00

自宅にあった、ここ５年間に読んだ論文を集めたらこれくらいになりました。（ちなみに全部両面印刷。ラボにも、もう1山分？くらいあります）

今や論文のPDFファイルはネットで簡単に入手できる時代で（ただし英語に限る）、画面の大きなディスプレイなら、そのまま読んでも特に不自由がありません。（なぜ印刷するかというと、電車の中やカフェで読んだり、お風呂で読んでも安心だったり（え？）、読み終わったら子どもに落書きさせたり（ええ？）するためです）。とにもかくにも、印刷された論文は家に置いておくとスペースをとってしまうので、1ページ目だけ読んだ記録用に残し、後は廃棄するために、子どもがホチキスの針をはがしてくれました。いい子。

ちなみに、ホチキスの針をはがすときには、「はりトル」がとてもとてもとても便利です。紹介していただいたkunishi先生に感謝。

優れもののステープルリムーバ、はりトルPro - kunishi's blog

関連

Leo's Chronicle: これから研究をはじめる人へのアドバイス（研究することと、そのための論文の探し方などについて）
Leo's Chronicle: Ullman先生からのアドバイス（工学寄りのアドバイスですが、論文を読みすぎてはいけない、など、大事な話が含まれています。）
サーベイに関するQ&A （住井先生、田浦先生）（研究者が普段どんな気分で論文を読んでいるのかがわかって貴重です）
論文での情報収集 - Loud Minority (瀬々先生による論文の読み方の丁寧な紹介。英語の論文を書く立場になって読む、という、これもまた大事な視点）

一人で悩んでいませんか？

2009-05-15T16:20:00.025+09:00

先日、痛ましい事件があったばかりですが、学生生活で困ったことがあった場合、一人で悩むだけではなく「勇気を振り絞って」相談してください。

例えば東京大学では、そのために学生相談所が設けられています。指導教員にまともに取り合ってもらえないことが原因なら、ハラスメント相談所などもあります。

特に修士・博士課程では、人間関係も狭くなりがちで、研究がうまくいくかどうか、それに伴う将来への不安など、極度のストレスにさらされます。「喉元過ぎれば熱さを忘れる」とはよく言ったもので、一度そのような辛い経験を経たはず人でも、十分な理解者となりえないことはよくありますし、家庭や人間関係など、置かれている立場が違うと、似たような問題でも、悩みの様相は変わってきます。

基本的に、大学は自らの意思で勉強する人をサポートする場所です。勉強の邪魔もしない代わりに、自分からアクションを起こさないと何もしてくれない場所、と考えた方が良いと思います。その例を挙げると、何もしなくても授業を受けられた高校までとは違い、大学では自ら履修届を提出する必要があり、自分自身で物事を判断する責任が求められています。日本に限らず、アメリカの大学でも状況は同じで、

困ったことがあったらメールでも、その辺で会ったときでもとにかく教授をとっつかまえて相談する
これが一番大切です。大切なことなのでもう一回言います。何か研究のことで困ったことがあったら、教授に相談する癖をつけてください。アメリカの大学院は、こちらからサインを出さない限り、基本的には本当に何もしてくれないし、ほったらかされる*1ので、とにかくアクションを起こすことをおすすめします。アクションさえ起こせば、たいがいのことはなんとかなります。

*1：何か困ったら助けてと言わずに放置して問題が悪化した場合、問題解決能力が無いとみなされる　ラボについて - Ockham’s Razor for Engineers

けれど、それぞれの事情を把握しているわけではないし、誰かに相談することで問題が解決するなどとはとても言えません。それでも、相談することで悩みを理解してもらえたり、あるいはもっとふさわしい相談相手に出会える可能性がある。ただその一点のみにおいて大事なメッセージだと思えるので、もう一度言います。

　「一人で悩んでいませんか？」

（追記）

相談所に限らず、家族、友人、恋人、教師、先輩、後輩。周りに相談相手が見つからなければネットにメッセージを投げてみるのも手だと思います。匿名で日記を書いてみる、日本がだめなら海外の人に聞いてみる。百人に叩かれても、たった一つのコメントで救われることもあります。

もう一つ。水村さんのエッセイ「日本語で読むということ」の冒頭にあったエピソードを紹介します。

Dan Gottliebという心理学者がいます。彼は事故で首の骨が折れ、胸より下が麻痺状態になってしまいました。今まで何不自由なく歩いていたものが、一瞬で、一生一人で手洗いにもいけない体になってしまったのです。家族、友人が去り、集中治療室で首を固定され夜一人横たわる彼の目に映るものは、集中治療室の冷たい天井の光のみ。仰向けに寝ているうちに、彼の心の内には自殺願望が膨れ上がってきました。

「もう死んだ方がましだ……」

と思ったそのとき、横から、女の人が話かけてきました。

「先生は心理学のお医者さまでしょう？死んだ方がましだって、そう思ったりすることって、よくあるんでしょうか。」

その女の人は病院の看護師でした。彼の症状などはおかまいなしにつらつらと悩みを話す彼女。そんな彼女が去ったあと、彼は心理学者としての自信を取り戻し「こんなサマになっても生きていける」と思ったそうです。やがて彼は復帰し、ラジオで人気の悩み相談の番組を持つようにまでなりました。

なんとか彼を励まそうとする家族や友人の善意あふれる言葉は、ちっとも彼の心には届かなかったのに、どう考えても自分より不幸な相手に向かって、心理学者ならきっとなんとかしてくれると、つらつらと悩みを打ち明ける彼女。そんな善意のかけらもない彼女の身勝手さがかえって彼を救った、という話です。

自分を救ってくれるのは、なにも、親身に相談を聞いてくれる人だけではないという、なんとも不思議な話ですよね。

（このエピソードは僕が短く直したものですが、水村さんの文章の方がはるかに情景あふれるものとなっているので、大変申し訳ないです）

データベースシステム入門：「データベースは体育会系図書館？」

2009-05-11T14:25:00.045+09:00

（データベースシステムとその研究の世界を一般の人にわかりやすく伝えるため、「図書館」をモデルにした話を書いてみました。試験に出そうな（？）部分は太字で強調してあります。）

データベースシステムは図書館

「データベース」という言葉は、データの集まりという意味です。データベースシステムの研究では、例えて言うなら「欲しい本がすぐに見つかる図書館」をいかに作るかという問題を考えます。ここで「データ」は図書館の「本」に相当し、「ハードディスク」は「本棚」がたくさん収められている図書館の建物だと考えてください。

「欲しい本がすぐに見つかる」とはどういうことでしょうか？例えば、図書目録を調べて目的の本棚の番号がわかったとしても、本棚までの距離が遠ければがっかりしてしまいますよね？（高すぎて手が届かない、とか泣けてきます）

「キャッシュ」は新刊コーナー

歩く距離を減らす工夫として、新刊書籍のように人気があるものは「新刊コーナー」にまとめて置いておくと便利です。この「新刊コーナー（あるいは人気の図書コーナー）」がいわゆる「キャッシュ」です。キャッシュはハードディスクより速くアクセスできる「メモリ」上に用意するのが普通で、図書館でいうと「受付カウンターの近く」というわけです。

重力・空間を無視して本棚を並び替えよう (B-tree)

しかし「新刊コーナー」の棚も大きさには限界があるので、入りきらない本のための本棚の方がどうしても多くなります。そこで、その本棚まで歩く距離（ディスクI/Oの回数）を減らすためにどうしたらいいかを考えます。現代社会に生きる私たちは、どうしても書店のように本棚を縦横に綺麗に並べたくなってしまいますが、そこはさすが1970年代の研究者。発想が違います。彼らは本棚を縦横ではなく、ピラミッド状に並べることを考えました。本棚を一つ設置したら、次は、1m空けて10個の本棚を並べる。そしてその10個の本棚それぞれにつき、また1mずつあけて本棚を10個並べる、といった具合です。

1m間隔で10,000個の本棚を一列に並べたら10,000mにもなってしまってとても大変です。この大変さを表すために、nを本棚の数として、O(n)（オーダー n）と書きます。これは、n=10,000のとき、10,000m歩かなくてはいけない本棚の並び方、ということを意味します。一方、ピラミッド方式だと、どの本棚にでも4m歩くだけで到達できます（4m = log 10,000、1mおきに10個の本棚があるので、10を4回かけて10 x 10 x 10 x 10 = 10,000個の本棚になる）。これをO(log n) （オーダーログn）と表します。ログオーダーのピラミッド方式では、本棚の数が10倍になっても、1mしか歩く距離が増えません（log 100,000 = 5。もしかしたら空中に浮かぶ本棚までジャンプする必要があるかもしれないですが…）。この本棚の配置はB-treeと呼ばれ現在最もよく使われています。

本はきちんと元の場所に整理して戻しましょう（インデックスとプロトコル）

ピラミッド型配置で本棚までの距離は短くなりましたが、これだけではまだ欲しい本が次の10個の本棚のうちどこにあるかまではわかりません。そこで、各本棚に、五十音やジャンル（小説、歴史など）のラベルを張っておきます。そして、本棚を、左から右の方向にジャンルごとに、しかも、五十音順に並べる、という索引（インデックス）を作るのです。抜き取った本を元の場所に戻さない悪い人がいると、当然この索引は役立たずになってしまいますので、ルールを守るように監視するのがデータベースシステムの仕事でもあります。このルールは「プロトコル（約束・手順）」と呼ばれます。

図書館は仲良く使いましょう（トランザクション管理、同時アクセス制御）

図書館の人が本棚に本を戻しつつ、たくさんの利用者が本を借りにくると、どうしても本棚までの通路が混雑して渋滞が起こってしまいます。この渋滞を解消するために、「今まとめて本を棚にもどすから、ここは通行止め（ロック）ね」とか、「こっちの棚は空いているからどうぞ」などと誘導して移動をスムーズにする（スループットを上げる）のが、「トランザクション管理」です。ロックなどを用いて複数の人の流れをコントロールすることを「同時アクセス制御（concurrency control)」と言います。

手狭になったらもう一つ増やそう　（分散データベース）

そして、一か所の図書館で蔵書や利用者の数をさばけなくなると「分館」を作ります。これがいわゆる「分散データベース」で、離れた図書館にしかない本が欲しい場合は、やむなく「取り寄せ（ネットワーク通信）」をするのですが、取り寄せはコストがかかるので、1つの本はあらかじめ3か所の図書館で読めるように3冊購入（といいつつ実はコピー）しておいたり（複製・レプリケーション）、近くの図書館同士なら取り寄せも簡単なので、敢えて離れた図書館に3冊目を置いておいて移動コストを減らす（分散配置・アロケーション）などの工夫もできます。

ハードディスクは体育会系？

そして図書館を形作る「ハードディスク」は、力持ちで大雑把なことは得意ですが、細かい仕事は苦手な体育会系なので、扱いがとても難しいです。「一列に並んだ本棚を100個まとめて持ってきて(シーケンシャルスキャン)」というと片手でひょいっと持ち上げるような頼もしいやつなのに、「こっちと、あれと、あそこと、あの本棚合わせて10個を持ってきて（ランダムアクセス）」というと、本棚100個を移動するより時間がかかってしまったりします。実際、上のハードディスクの写真を見てもらうとわかりますが、ハードディスクというのは要するに回転するレコードに針を当ててデータを読む構造なので、針を細かく動かす仕事は苦手です。そんな彼のために、「とりあえず100個をここ（バッファ）に持ってきて。あとはこっちで探すから」という指示を出すのもデータベースシステムの仕事です。最近流行りのフラッシュメモリー（SSD）も仕事は速いけれどどうやら体育会系脳はそのままのようで。

Leo’s Chronicle: Flash-Based DBMSの最前線

ここに挙げた項目はそれぞれ奥が深く、今でも熱心に研究されています。そして、ハードディスクのような体育会系脳をいかに賢くするか、というのがデータベース研究の醍醐味でもあります。それに関連する話はまた次の機会に。

（体育会系の人がアホだとか言っているわけではありません。あしからず）

NHK高校講座世界史がすごい

2009-05-05T11:32:00.014+09:00

何気なくテレビをつけていたら、NHK高校講座が放送されていました。これは面白い。

さすがに、数学など「問題を解く」系統の科目は、いくら資料がよくできていても、自分の理解のペースにどうしても合わなくて（もう先に進んでよ～、あれ、そこはそんなにあっさりなの？、というように）居眠りしてしまいそうになるのですが、「世界史」のような歴史科目は、人物や資料などの映像があってこそだと実感。

なにはともあれ百聞は一見。2008年分の全放送がインターネットから閲覧可能になっているので、ぜひご覧あれ。

NHK高校講座世界史ライブラリー

パレスチナの紛争を生み出した元凶など、いまさら聞けないと思っている方にもお薦めです。（パレスチナ問題に関しては、The Economist誌なども歴史を振り返る記事を書いていましたね。「The Arabs and Israel - The hundred years' war」）過去を知らずして、今を理解することは到底できません。NHKのように映像のアーカイブを残す試みは素晴らしいと思います。

映像があるのとないのでは興味の持続の仕方が全然違います。山川の詳説世界史研究などの内容と比べるとテレビで扱われている分量は少ないのですが（資料映像など、本よりも充実している面もありますが）、やはり、これだけの分量の歴史解説を何の刺激もなく読むというのは大変なもので、より詳しく知る前のappetizer(食欲をそそるもの)としてNHK高校講座は十分活用できるのではないでしょうか。

蛇足ですが、進行役の寺田ちひろさんを見るだけでも価値があるかと。テレビ慣れしていない教授陣を、するどいコメントで誘導していく様は、ある意味爽快です。（もちろん台本はあるのでしょうが）

関連

世界史講義録　（高校世界史の授業録。こちらも、読み物としてものすごく面白いです。初回の授業に感動しました）

もしもサーバー管理ができたなら

2009-05-04T10:44:00.007+09:00

なんだかとても残念な話。

大学の研究の都合でサーバーの構築が必要に。Linux未経験の女子学生が立候補。彼女をバックアップするためにラボ一丸となって準備に奔走する。

けれど、後に、他にサーバー管理ができる子がいたことがわかって、たいそうショックを受け卒倒しそうになりました、ということです。

この「サーバー管理ができることを隠す」という気持ちは、なんとなくわかります。僕自身も学生時代、能ある鷹は爪を隠す、とまでは言わないけれど、同じ雰囲気を感じたためか、サーバー管理ができることを大っぴらにはしていなかったように思います。現に、大学時代の友人の中には、僕がサーバー管理ができることを今更ながらに知って驚いた人もいます。

それでも、上の話のような事態にならなかったのは、他にもLinuxが好きな子がいて、その子は率先してマシンに触りたいタイプの人だったので、特に困らなかったというだけ。

自分自身を鑑みて、元の話の彼が「サーバー管理ができる」と言い出さなかった理由はいくつか思い付きます。

「自信がなかったから」うん。これはありそう。まだプロじゃないだろうし、クラックされてすべて自分の責任にされてはたまりません。

「自分がいなかったらどうするんだろう？」という興味。大学のラボでは、なにかとサーバー管理をする子が必ず一人はいるようになっていて、どうしてそれが成り立つのかいつも不思議に思っていました。もし、誰もサーバー管理ができなかったら、この状況をどうやって乗り切るのか、とても興味があります。別段、皆を困らせたいわけではないのだろうけど。

「Linuxが使えるのだから」と言われることへの嫌悪感。Linuxが使えるというだけで、サーバー管理者になることが既に決まってしまっているというのは、その人がサーバー管理能力を身に付けるためにLinuxと戯れた時間や英文セキュリティレポートを読む努力にタダ乗りしているようなもので、フェアではないと強く感じます。あわよくばタダ乗りしようとしていたのを棚に上げて、皆で努力していた間、隠していたのは何事だ、というのではあんまりです。

一方、サーバー管理ができることを隠していたがために、悔しい思いをしたこともあります。とある業者にシステム一式の納入と設定を依頼したときのこと。やってきた担当者の知識がとにもかくにも足りないわけです。けれど、その時は研究する時間を確保する方が大事だったので、担当者ができないことなぞ気にも留めていませんでした。

すると2か月たっても設定が終わらないので、その業者に問いただしたところ、

「Linuxは設定が大変なんですよ。知らないんですか？」

と言うのです。このときばかりは、はらわたが煮えくりかえりました。その見下した態度はなんだ。単にDNSの設定すらできないだけじゃないのか、と。（隠しているこっちもこっちなので、おあいこなのですが）

とまぁ要するに、最後の可能性として、その業者の

「技術力が低かった」

だけなのかもしれません。元も子もないですね。お後がよろしいようで。

（この話はフィクションのはずです）

関連

もしもピアノが弾けたなら

2009-05-04T00:10:00.015+09:00

なんだかとても残念な話。

文化祭で、出し物の都合でピアノ奏者が必要に。ピアノ未経験の女子生徒が立候補。彼女をバックアップするためにクラス一丸となって準備に奔走する。

けれど、後に同窓会で、他にピアノが弾ける子がいたことがわかって、たいそうショックを受け卒倒しそうになりました、ということです。

この「弾けることを隠す」という気持ちは、なんとなくわかります。僕自身も高校時代、能ある鷹は爪を隠す、とまでは言わないけれど、同じ雰囲気を感じたためか、楽器が弾けることを大っぴらにはしていなかったように思います。現に、高校時代の友人の中には、僕が楽器を弾くことを今更ながらに知って驚いた人もいます。

それでも、上の話のような事態にならなかったのは、他にもピアノが上手な子がいて、その子は率先して人前に出るタイプだったので、特に困らなかったというだけ。

自分自身を鑑みて、元の話の彼が「弾ける」と言い出さなかった理由はいくつか思い付きます。

「自信がなかったから」うん。これはありそう。まだプロじゃないだろうし。

「自分がいなかったらどうするんだろう？」という興味。学校のクラスはなにかとピアノ演奏をする子が必ず一人はいるようになっていて、どうしてそれが成り立つのかいつも不思議に思っていました。もし、誰もピアノが弾けなかったら、この状況をどうやって乗り切るのか、とても興味があります。別段、皆を困らせたいわけではないのだろうけど。

「ピアノが弾けるのだから」と言われることへの嫌悪感。ピアノが弾けるというだけで、弾く役になることが既に決まってしまっているというのは、その人の演奏能力を身に付けるための練習時間や努力にタダ乗りしているようなもので、フェアではないと強く感じます。あわよくばタダ乗りしようとしていたのを棚に上げて、皆で努力していた間、隠していたのは何事だ、というのではあんまりです。

一方、音楽ができることを隠していたために、悔しい思いをしたこともあります。野球部の地区予選の応援にクラス全員で行ったときのこと。相手高の吹奏楽の応援がまぁとにもかくにも下手なわけです。けれど、僕は野球を見ることそのものが好きだったので、下手な演奏なぞ気にも留めていませんでした。

すると、隣にいた例のピアノが上手な子が一言。

「（演奏の下手さに）気付かないのって幸せだよね」

と言うのです。このときばかりは、はらわたが煮えくりかえりました。その見下した態度はなんだ。音楽ができるのがそんなに偉いのか、と。（隠しているこっちもこっちなので、おあいこなのですが）

とまぁ要するに、最後の可能性として、そのピアノが弾ける子の

「性格が悪かった」

だけなのかもしれません。元も子もないですね。お後がよろしいようで。

「正直」である前に「真摯」であれ～草彅君の謝罪会見で感じたこと

2009-04-27T10:11:00.021+09:00

真摯（しんし）であることと、正直（しょうじき）であること。この二つは似ているようで、与える印象はかなり違うものです。先日の草彅君の謝罪会見のおかげで、「正直」と「真摯」の違いに関する例をいくつか思い出すことができたので、ここに挙げてみます。

以下は、温暖化ガスによる環境問題で、ガソリンの代わりに、バイオ燃料と言われるエタノールを使うことのデメリットを紹介したThe Economistの記事：（一応リンクは張ってありますが、原文はThe Economistの購読者しか読めないようです。すみません)

And when Henry Ford was experimenting with car engines a century ago, he tried ethanol out as a fuel. But he rejected it—and for good reason. The amount of heat you get from burning a litre of ethanol is a third less than that from a litre of petrol. What is more, it absorbs water from the atmosphere. Unless it is mixed with some other fuel, such as petrol, the result is corrosion that can wreck an engine's seals in a couple of years. (Henry Fordが一世紀ほど前に、エタノールを燃料として使ってみようとしたが、この案は却下されることになった。これにはちゃんとした理由があって、エタノールを燃やしたときの熱量はガソリンの3分の1以下にしかならず、さらに空気中から水分を吸収してしまうので、他の燃料、たとえばガソリンなどと混ぜない限りエンジンのコーティングを数年で腐食させてしまうからだ。) - Ethanol, schmethanol. The Economist, Sep 27th 2007.

この記事を読んで僕は、トウモロコシなどから取れるエタノールなどのバイオ燃料は、騒がれている割に実際はだめなのかと、しばらく思いこんでいたのですが、ブラジル出身の人から聞いた話だと、ブラジルではエタノール燃料の方がむしろ主流で、ほとんどの車がエタノール燃料で動いているし、エンジンの痛みも別にガソリンと変わらないとのこと。この話を聞いて、僕としてはなんだかThe Economistに騙された気分になったのですが、その後、同誌の読者からの意見のページ(Letters)で、以下のようなコメントを見つけました。

It would also do more to encourage the use of vehicles with flexible-fuel engines to provide American consumers with something they do not have: a real choice. In Brazil 80% of new vehicles run on ethanol, petrol or a mixture of both. There is no special tax rebate for these cars: we buy them because we want to. （（もしアメリカがエネルギー問題を真剣に考えているなら）アメリカの消費者が持っていない多燃料対応の車（これは実際の選択肢として存在する）を使わせるようにするべきだ。ブラジルでは80%の新車が、エタノール、ガソリン、またはその両方を混ぜたもので動くし、そういった車に対して税金の払い戻しなどもない。皆、必要だから買うのだ。）- From Letters, The Economist. Oct 11th 2007

これは明らかに記者の認識不足を指摘した意見なのですが、それにも関わらず、そのような記事をきちんと紹介している姿勢に、The Economist誌の「真摯」さを感じることができました。「間違いを指摘した意見は載せたくない」とか、「あの記事には間違いが含まれておりました。大変申し訳ありません」という対応が、「正直」な気持ちをそのまま表現したものだと思いますが、読者としては、そのような「正直」な姿を見たところで得るものは少ないです。

もう一つの例。大学のとある卒業審査のための発表会での話。

（先生）「その研究は、既存のツールを使いまわしただけじゃないのか？」

（学生）「（しばらく悩んで）…、はい。そうです。」

これも、「正直」の例。正直なのは結構だけれど、審査する先生方もおそらくその「正直さ」を求めているわけでありません。例えば、「使った技術は既存のものの組み合わせだけれど、それでもこの問題に取り組むことは大事なんだ」と言えるだけの、研究に対する「真摯」な姿勢。それを見せる方がきまって良い印象になります。

そして、草彅君の謝罪会見。「また楽しいお酒が飲めるようになりたい」と言うような「正直」さが好感を得ている、という報道もありましたが、それよりも、彼が慎重に言葉を選んでいる姿、自分の置かれている状況や、自分の行為、言葉が世間に与える影響などを真剣に考えている。そんな様子を容易に見てとることができたので、ただ正直に謝るではなく、真摯に向かうその姿勢こそが大事なんだということがよくわかりました。自分の犯した罪に真剣に向き合う。ただ愚直に発言を撤回するのとは質の違う「真摯さ」。

僕自身も「正直」である前に「真摯」でありたい。そう思います。

(追記）

「草彅（なぎ）」君の漢字を、「草薙」と書き間違えていたので修正しました。まさか、こんな形で、このエントリに書かれていることを実践することになるとは。。。id:poccopenさんに感謝。

ごめんなさいごめんなさいごめんなさい

2009-04-24T10:03:00.001+09:00

机の上にごちゃごちゃ物を置いているやつは総じて能力のないプログラマー
新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件 - ハックルベリーに会いに行く

ごめんなさい
ごめんなさい - 西尾泰和のはてなダイアリー

ごめんなさいごめんなさい　(IT戦記)

もひとつ、ごめんなさい

Flash-Based DBMSの最前線

2009-04-16T09:45:00.049+09:00

フラッシュメモリーを使ったSolid State Drive (SSD)の容量が160GBに到達し、市場価格も下がってきたことにより、ハードディスクの代替品としてSSDを使う用途がいよいよ現実味を帯びてきました。低容量のものなら既にiPodやデジカメ用のメディアなど身の回りにも普及しており、市場ではすでに「破壊的イノベーション（「イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき」より）」が起こっているといえます。（HDD搭載のWalkmanとか既に滅んでいる例もあるし。。。）

では、SSDの登場によってデータベースシステム(DBMS)の実装はどう変わるのか？2009年4月現在の最新論文リストをPFIの太田君が紹介してくれたの

で、データベース国際会議の最高峰であるSIGMOD, VLDB, ICDEや、DaMoNワークショップ（新しいハードウェアに特化したDBの研究会）の論文を中心に紹介します。こういうのは速さが勝負なので、まとめて午前中に読んでみました。

まず前提知識として、SSDの特徴は、Sequential Read(連続したブロックを読む）、Random Read（ランダムな位置のブロックを読む）の性能が従来のハードディスク(HDD)に比べて2~10倍以上、製品によっては100倍以上速いこと。

ちなみに、IntelのX25M(80GB/160GB)では、それぞれの操作で最大：

Sequential Read: 250MB/s, Sequential Write: 70MB/s
Random Read: 35000 IO/s, Random Write: 3300 IO/s

一方、Seagateの7,200RPMのHDDでは、

Sequential Read: 120MB/s, Sequential Write: 120MB/s
Random Read: 100 IO/s, Random Write: 110 IO/s

このデータだけみると、Sequential Wite以外すべての面においてSSDがHDDを上回っていますが（Intel X25Eにおいては、Sequential Writeが170MB/sになって完全にHDD上回っています）、これはハイエンド製品のデータで、巷に出回っている１～２万円台の低価格SSDはRandom WriteがHDDより遅いのが普通です。(とある32GB SSDでは、Random Read: 3100 IO/sに対し、Random Write: 25 IO/s だとか。HDDよりrandom writeが遅いです)。

SSDの特徴をまとめると

read/writeのパフォーマンスが全体的に向上　(1)
random read/random writeのパフォーマンスに差があること (2)
random writeがHDDより遅いことがある (3)

このうち(1), (2)はHDDより性能が上がるだけなら、既存のDBMSがそのまま速くなって嬉しい。これは、kazuhookuさんのエントリ「 SSD がコモディティになっても状況はかわらない」にあるとおり。ただし、2008年前半は、Random WriteがHDDより速いIntel X25シリーズが出ていなかったので、(3)が深刻な問題でした。そして、実は、今出ている論文というのはこの製品が出る前の研究であるので、(3)の問題を真面目に扱っています。（国際学会の論文というのは、最先端から半年～1年遅れで出てくるものだということは踏まえておいてください。研究の最前線は常に研究者の頭の中です。）

それゆえ残念なことに、今普及している低価格のSSDには効果がありそうだけれど、今後は不要になりそうなアプローチの論文というのもあります：

S. W. Lee, and B. Moon. Design of Flash-Based DBMS: An In-Page Logging Approach. SIGMOD 2007. [pdf]　（SSDのrandom writeが遅いので、データページ内にログも配置するとDBMSが速くなるという研究）
Y. Li, B. He, Q. Luo and K. Yi. Tree Indexing on Flash Disks. ICDE 2009. [pdf] (Random writeが遅いSSD対策として、B+-treeに独自のページレイアウトをmergeして、insertionの性能を上げた研究。Random Writeが遅いSSDで実験しているから速い結果がでているけれど、IntelのX25シリーズを使ったり、key値だけでなくclustered-indexを使った場合や、ロック処理までちゃんと実装したら、実際のinsertion, throughputの性能差はほとんどないと思われる。）

これらのアプローチはもはや時代遅れに思えてきます。一方、(3)が問題だった製品を使っているにも関わらず、SSDのDBMSにおけるメリットを適格に示している論文は、Samsungのチームが関わっている以下の研究：

B. Moon, C. Park, S. W. Lee. A Case for Flash Memory SSD in Enterprise Database Applications. SIGMOD 2008. [pdf] 　(SSDを使うと、更新の時系列に沿ってバージョン番号が付けられたrecord chainの探索(MVCCで使う）が速くなり、大規模データの問い合わせに必要な、external merge sort, hash joinの性能(ともにrandom readが多発）が高速化されることを検証した論文)

上の論文の実験でも同じシステム構成を用いているのですが、HDDとSSDを組み合わせて使うアプローチを提示しているのがこれ：

I. Koltsidas, and S. D. Viglas. Flashing Up the Storage Layer. VLDB 2008. [pdf] （これもまだ(3)が問題だった当時の話なのですが、状況によってディスクページの保存先をSSD, HDDと切り替えるアルゴリズムを提案しています）

SSDの価格が十分に下がるまでは、このように、random readを速くしたいときはSSD、大きなデータをとりあえず置いておきたいときや、sequential writeでもいいという場合はHDDという素直なアプローチも悪くないと思います。

「5分間ルール」から20年

1987年にJim Gray（Jim Grayに関してはこちらのエントリの最後で紹介しています）が、「5分間ルール」と称して、性能やそれに応じたストレージ価格コストを考えると「5分以内にアクセスされるデータ(4KB程度）はメモリに置いておくべきだ」という提案をしました。その10年後は、HDDのアクセススピード向上は比較的緩やかだったのに対し、ディスクの容量がメモリに比べて急激に上昇し価格は下がる、という状況が相まって、「5分間ルール（１０年後）」は維持されていました。

20年後、SSDが登場して、「5分間ルール」はどうなったのか？というのが次の論文：

G. Graefe. The Five-Minute Rule Twenty Years Later, and How Flash Memory Changes the Rules. DaMoN 2007. [pdf]

結論を言うと、「5分間ルール」はSSDに関してはそのまま。ただし、HDDに関しては256KBまでページサイズ(B+-treeのリーフなど）を増やした方が検索性能が良くなっている。SSDだと、従来通り2KB~4KBくらい小さなページサイズが速い。従って、HDDとSSDを共に使う場合、それぞれで最適なページサイズの不均衡があるので、先の'Flashing Up The Storage Layer'のような工夫が必要になるよ、という話。SSDを、メモリバッファの拡張としてとらえるか、HDDの拡張として使うかで、アプリケーションや、最適なアルゴリズムも変わることが示唆されており、SSDの利用価値がどこにありそうかを検討するブレインストーミング用の論文として便利だと思います。ちなみに、2種類のページサイズを使い分けるB-Treeは、すでに考案されている（SB-Treeというらしい）ので、こういうったものを実装してみるのも手。

ただ、「B木 - naoyaのはてなダイアリー」で触れられているようなSSDがB+-Treeを駆逐するイノベーションというのはどうも感じられていません。そもそも、B+-treeの構造と、バッファ管理、ログ、ロックやスナップショットなどのトランザクション管理は今でも十分切り離せてなくて、B+-tree以外の索引構造もいままでいろいろ研究されてきましたが(R-treeとか）、検索専用には使われても、更新用途にはどれも生き残っていません。（トランザクション管理の難しさについては、こちらを参照してください：Leo's Chronicle: Top 5 Database Research Topics in 2008）

率直なDB研究者としての意見は、

DB研究者って、どうもSSDにはまだ悲観的な気がしているのだけれど、ここで、破壊的イノベーションが起こってあたふたしたりするのだろうか
http://twitter.com/taroleo/status/1506861323

という消極的なものですが、本当は、あたふたするような事態があった方が、研究テーマが増えて面白くなるので、非常に期待はしています。破壊的イノベーション（適用分野、マーケットががらりと変わってしまうような発明）は、アプリケーションの変化に起因するものだとも思います。SSDの真の価値は、既存のDBMSが進化していく方向にではなく、まったく新しい用途のDBMSを作り得る点と考えると、今後SSDの動向を追うのが楽しくなるのではないでしょうか。

関連

学生を成功に導くアドバイス - Ullman先生からのアドバイス

2009-04-02T11:46:00.050+09:00

(この文章は、Ullman先生に許可をいただいて翻訳し掲載しているものです。記事の掲載を快く承諾してくださったUllman先生に感謝）

学生を成功に導くアドバイス
～学生にアドバイスをする教師へのアドバイス（そして、教師が学生から学べること）

Jeffrey D. Ullman

（原文：Advising students for success. Communications of the ACM, Volume 52, Issue 3. March 2009.）

博士課程には、二人として同じ学生はいない。そして、教師がすべきことも個々の学生に応じて変わる。自分のキャリアを振り返ってみて、うまくいったいくつかの方法と、よく使われているけれど実際には学生のためにならないやり方というのがよくわかるようになった。まず初めに述べておくと、教師のゴールとはどうやったら学生が自分自身の力で考え、新しいアイデアを組み立て、問題を解ける人になれるかを教えることだ。

2003年のJeff Ullmanの退官式にて。参加した学生と同僚たち。
（訳者注: 中央左がUllman先生。左端にはJim Gray、中央右にSergey Brinなども）

教師であるあなたは、十代を終えたばかりの学生を受け持って、その分野で最も経験のある誰もができなかった何かをできることを、学生に実感させなければならない。そして、それがただの一回だけでなく、プロとしてそれを生涯続けられるようにしないとだめだ。率直に言って、私が学位を取ろうとしていたときには、博士論文に何を書いていいかわからなかったし、もしわかっていたら、大学院には行っていなかったに違いない。

やってはいけないこと

私は学生で、その後、大学の教員になった。私がいた電気工学科では、学位論文を書く方法は、たくさんの論文を読むことだという考えが定着していた。「論文の最後の章を見ろ。そこには常にopen problem (未解決問題）のリストがある。その中から1つを選んで研究し、ほんの少し発展させられるまで続けるんだ。そしてその小さな成果について論文を書き、最後に必ずopen problemの章を入れるのを忘れるな。そこに、君ができなかったことを全部書くんだ」という具合にだ。

不幸にも、この論文の書き方は今でもあちこちで行われており、凡庸な研究を助長している。そして、研究というものが他の誰かの仕事に小さな成果を付け加えることだという幻想を生んでしまっている。さらに悪いことに、そうしているうちに研究が「解くべき問題」ではなく、「解ける問題」によって左右されるようになる。論文を書き、論文を採録するのも、そのような小さな成果を付け加えるような論文を書く人たちになるが、それでは論文が物書きの世界を超えて世の中に与える影響というのは大したものにはならない。

初期の形態：理論中心の学位論文

コンピュータ科学がまだアカデミックの世界に出はじめの数年は、多くの論文が「理論的」であった。それというのも、論文による貢献がほとんど「紙と鉛筆」によるものだったからだ。定理やアルゴリズムとかそういうもので、ソフトウェアではなかった。そのような研究は、机上の空論に終わるかもしれないという弱みがあったが、理論的な論文が実際に役に立つことは十分ありえる。例を挙げると、私がプリンストン大に入る前、ベル研でRavi Sethiのもとで夏のインターンをしていた時のことだ。Ken ThmpsonとDennis RitchesがMultics（GE635計算機のためのOS）のプロジェクトに参加していた。この猛獣のような計算機は、初めて1つ以上計算に使えるレジスタを持ったもので、Raviと私に与えられた課題は、コードをコンパイルし、レジスタを最大限活用する技術の開発だった。Raviの論文は、数値演算の式をコンパイルし、与えられた数のレジスタを使って最小限のステップで計算するアルゴリズムについてだった。これは実際に数年後、PDP-11用のC言語のコンパイラに組み込まれた。

Raviの論文は「理論的」であり、私も彼も一切コードを書かなかったが、この経験は、私にどんな学位論文でも実際に開発すべきものなのだと確信させる経緯を物語っている。私たちの研究は、どこかの論文に書かれたopen problemに基づいたものではなかったし、むしろ「いくつかのレジスタを使って式をコンパイルする」という要求に応えたものだった。私たちの大きなアドバンテージは、分野を開拓してく力強さを持った環境に身を置いていたことだった。もし、ベル研にいなかったら、この問題に取り組む価値があると気付くことができたかどうかも疑わしい。我々が用いたノードへの順序づけの方法を先に論文にしていたAndrey Ershovでさえ、その研究を１レジスタのマシンでコンパイルする手法としてしか見ていなかったし、論文中で複数レジスタを持つマシンでの可能性などは示唆していなかった。

理想的なPh.D.の学生

一番理想的なシナリオは、学生が私にどんな論文を書きたいかを話して自分自身で研究を行い、かつ、学生がその論文のテーマを選んだ理由が、実際の「顧客」のニーズに基づいている場合だ。Sergey Brin (訳注：後にLarry PageとともにGoogleを起業した)は、この理想に最も近かった。というのも、BrinとLarry Pageの2人は私の助けを一切借りずとも、良い検索エンジンの必要性を認識していたし、その目標にどうやって到達できるかもスタンフォード在学中に見据えていた。ただ１つ欠けていたのは、彼らの2人とも博士の学位をとらなかったことだ。とはいえ、のちにより大きなものを手にするのだが。

さらに似たような例として、George Luekerがいる。彼はある日、私のもとに論文のテーマが何かないかと尋ねに来た。Georgeは、その時は私の学生ではなかったが、プリンストン大で応用数学のプログラムに所属していた。私はその日の朝、chordalグラフについて読んでいて、chordalityを検出するアルゴリズムはどうかと彼に提案した。1年後、彼は再びやってきて、pd-treeについて書いた彼の論文を見せてくれた。そのデータ構造は、chordalityの検査の他に、今でもいくつかの重要なアプリケーションがあるものである。他にも何人もの学生が、渋る私をけしかけて、新しい分野を学ぶ方向に引きずりこんでいった。その後、逆に私が彼らの論文テーマ選びに関わることもあったのだが…。Matt Hechtは、私にデータフロー解析について学ばさせてくれたし、Allen Van Gelderのおかげで、ロジックプログラミングを学ぶことになった。

なぜ「誰が」論文のテーマを提案するかが重要なのか？私たち教師は、若い科学者が、自分自身の力で取り組む価値があるものを見つけられるように導こうとしている。その過程では、いくつかの判断が必要だ。何がやる価値があるのか？何が実現可能か？そして、どうやってそれをやるか？だ。教師はこれらの判断を助けてあげることもできるが、自分の力で自然にこの域に到達する学生に出会うのは楽しいものだ。それに、年をとるにつれ私が忘れないように心掛けていることは、若い人は、すでに自身の流儀に落ち着いてしまった我々にはできないようなものの見方ができる、ということだ。若い人の技術的な判断を信用するのも悪い戦略ではない。

学生は何を必要としているか

「学生を成功に導くには、多くのサービスを与える準備ができている必要がある。」

「『顧客』を見つけてあげること」。この記事の初めでも述べたが、分野の最先端の問題に触れる必要があり、その問題が実際の「顧客」に必要とされていることが大事だ。ときには産業のなかで「顧客」を見つけることもできる。私とRavi Sethiがベル研でそうであったように。そのために夏のインターンシップはとてもよい機会になりうる。しかし、教師は学生に強い研究グループでインターンをするように薦めるべきだ。強い、というのは、そこでの研究のゴールが、既存の手法に単にひねりを加える以上のことをしている、という意味でだ。

論文が理論的であれ実装による解決であれ、研究がうまくいったときに、学生がその研究の成果を実際に誰が使うことになるのか理解できるようにする必要がある。そしてその答えが、「誰かが僕の書いた論文を読んで、論文中のopen problemを使って自分の学位論文を仕上げるさ」となるようではいけない。特に理論的な論文に関わる場合は、研究が活きる連鎖が生まれるまでの道のりは長いかもしれない。アイデアがアイデアを生んで、研究成果が行きわたる状態に至るまでは。もし、学生にそんな連鎖や研究成果が生かされる道が本当にあるかどうかを無視させてしまうようでは、教師は学生へのサービスを損ねていると言える。

「走り出す前に歩み出すこと」。問題に触れさせるだけでは十分ではない。部分的に、完全にではなくてもよいが、Ph.D.の学生が、自分自身でオリジナルなことをできると自信を持つ必要がある。以下に、実際にうまくいったアイデアをいくつか紹介する。

研究を始めたばかりの学生に、研究の在り方を掴む練習をしてもらうには、あなた自身が小さな問題を通して考え、博士課程の学生にその問題に取り組むように指示するとよい。あなたの頭の中で既に道筋が付けられているので、学生をあるべき方向に誘導するような質問をぶつけるのは簡単で、学生が自ら解法に至るまでそれを続けさせることができる。このような小さな体験だけでも、たいてい、学生が自分で研究に取り組めるようなるのには十分だ。
学生がなるべく早く、論文を読んでいるだけの状態から抜け出し、自分自身のアイデアを生み出せるようにすること。確かに、たくさん論文を読まないと分野の知識を得ることはできないのだが、ある時点から先は、読めば読むほど、考え方がその分野の大勢一般の考え方に近づいてしまい、「枠を超えた」思考というのが難しくなってしまう。もし、学生が見込みのあるアイデアを生み出したなら、もちろん、注意深く既存の文献を探さなければならない。十分な例を通して見た経験から、学生のアイデアが既存の研究の枠内に完全に納まってしまうのは稀であると信じている。（悲しいことに、そういう場合もあるにはあるのだが）。
同僚のHector Garcia-Molinaはよく学生に、理論的に最適な解法を探すことから始めるのではなく、単純で、簡単に実装できる解法で90%のゴールになるものを探すようにと指導している。最適性はあとで研究して、学位論文の重要な部分を形作ることができるからだ。
もう一人の同僚のJohn Mitchellは、学生が自分で新しいことができると信じる、というハードルを乗り越えたあとでさえ、学位論文の規模の大きさには委縮してしまうことを指摘してくれた。彼は、とりあえず学生に論文を1つ書くことに集中させている（より良いのは、論文誌ではなく、人に会う機会が生まれる学会のための論文を書くことだ）。学生がいくつかの論文を書いた後、それを元に学位論文を書けば、怖さが軽減する。

「アイデアを表現すること」。教師は、学生が明瞭な文章を書けるように指導しなくてはならない。良いアイデアを学生がうまく伝えることができていなければ、細かい点まで指導する。アドバイザーは論文をかなり丁寧に読見込んで、一文ずつチェックするのが、学生が最初に論文を書くときには大事だ。よくあることだが、早いうちに見つけなくてはいけないのは、簡単な部分については細かいところまで書きこんでいるが、難しい部分になると、たとえば、核となる定理の証明や複雑なアルゴリズムの細部で、非常にあいまいな記述になったり、おおざっぱすぎになったりする場合だ。教師は、難しい部分を判断し、難しい部分がしっかりと書かれるようにしないといけない。(*)

(*) 最初のうちは細かいことのように聞こえるだろうが、論文を非常にわかりやすくする方法は、何も指していない"this"という言葉を学生の論文から探すことだ。多くの学生が（学生以外の人も）"this"を一つの名詞ではなく、ある概念全体を指すのに使ってしまう。例えば、「If you turn the sproggle left, it will jam, and the glorp will not be able to move. This is why we foo the bar.（sproggleを左にまわすと詰まって、glorpが動けなくなる。だからfooしてbarなんだ)」という文。ここで、書き手の方は、sproggleとglorpが何かわかっているので、"This is why（だから）」で示される「fooしてbar」と言える理由が、glorpは動かないからとか、sproggleが詰まっているからなどと理解できる。けれど、まだglorpやsproggleがどう動くかまだよくわからない読者の立場になって、パラグラフを注意深く書くことが大切だ。今では何も指していない”this”を見つけるのはそう難しいことではない。このようなthisはほとんど文頭にあるので、grep（訳注: 文字列検索プログラム）を使って"This"を検索すればよいだけだ。

「怖がる要因」。もう一つ教師に共通する仕事は、学生が、充実感を持ったまま、何も恥じることなく失敗できるようにすることだ。すべての学生が失敗することへの打たれ強さを持っているわけではないし、多くの学生が、まだうまくいくかよくわからないことを試すのが悪いことだと思ってしまっている。大抵の場合、学生の考える「問題」のモデルは、「宿題」から来ている。つまり、答えがわかっているものだ。そして「今週は何もできませんでした」と報告することを恥じている。たとえそれが、努力不足によるものではなかっとしてもだ。教師であるあなたも、学生が多くの時間をプログラムを書くこと、しかも、人の書いたプログラムを入力として受け取り、その中に含まれるすべてのバグを取り除くようなことに費やしてほしくはないだろう。（実際、私の同僚の学生は、一度師匠にそんなことをやれと言われていたが）。でも、学生に挑戦的でリスクもあるような仕事を薦めるのは大丈夫だ。例えば、他の誰よりもバグをたくさん見つけなさい、というような。その場合、教師の極めて大事な役割は、学生に費やす時間と努力、つまりリスクを承知の上で研究させ、何も良い成果が出なかったときのケアをすることだ。

「集団療法」。よく使われる方法で、学生を励ましつつ研究に邁進させるのに良いのは、フリーのランチだ。Ph.D.の学生のためだけでなく、学部生を研究の輪の中に引きつけるのにも使える。過去15年間、幸いにも私は、スタンフォード大の「データベースグループ（現在のInfolab)」の中にいることができた。メンバーには、Gio Wiederhold、Hector Garcia-Molina、Jennifer Widom、学生、スタッフ、そして外から来ている研究者もいた。金曜日に開かれる定期的なランチでは、学生は自分の研究についてインフォーマルな話をし、良い感じの議論がフロアでなされるのが通常だった。学生が次の学会の発表練習をしても良いし、同僚の学生から細かい点まで指摘を受けることもできる。ランチのもう一つの重要な役割が、つながりにある。グループ行事を行う社会的な集まりのなかでつながりが強くなり、定期的にある出張レポートが、外の世界について学ぶ原動力になる。

新しい形態：プロジェクトに基づいた学位論文

この段階に至るまでは長い年月がかかったが、今やたくさんのソフトウェアプロジェクトが、アカデミックの世界で日常的に行われるようになっている。それでも、純粋に「紙と鉛筆」で書かれた学位論文というのも常にあるものだが、もっと生産的な方法が、Ph.D.コースに入りたての学生をソフトウェアプロジェクトに参加させることだ。たいてい、学生は「何かをしながら学ぶ」経験ができ、ソフトウェア開発に貢献し、それと同時にプロジェクトで研究された新しい概念を学んでいく。年輩の学生は、後輩の学生を助けたり、教える経験を積む機会にも恵まれる。

この研究の形体を効率的に使った一番良い例は、同僚のJennifer Widomによるものだ。たくさんのイノベーションを生んだプロジェクト（半構造データ、ストリームデータベース、そして今は、不確実データのデータベース）の中で、Jenniferは次に挙げるルーチンを完璧にこなした：

1. 研究の大まかなゴールを定め、一緒に取り組む博士課程の学生のチームを作る

2. 相当の期間の時間（6～12か月くらい）を、問題に潜む基礎的な理論やモデルの構築に費やす。（Jenniferが言うには、学生を研究計画とモデルづくりの段階で巻きこむのが、彼女のやり方の際立った特徴だとか）

3. それから実装のためのプロジェクトを始める。細かい点を学生に取り組んでもらう。個々の開発プロジェクトのゴールは、ちゃんと動いて配布してもいいようなプロトタイプを作ることで、商用化できるくらい完璧なものを作ることではない。

4. 学生に、幅広い問題分野から集中して取り組むべき難しい問題を、自分なりに切り出させる。学生は自分のアイデアを組み立てていき、それが学位論文の核となり、さらに、大きなシステムの一部として自分のアイデアを組み込むことで、そのアイデアをの価値を検証できるようになる。

悲しいことに、多くの研究ファンド（たとえばDARPAなど）が、最近かなり「ミッション重視」になってきている。プロジェクトの実装の一部でPh.D.の学生をサポートできるかもしれないが、それではプロジェクトの枠を超えて自分独自の仕事をする余地がない。例えば、私はそれぞれ別の情報源から同じことを聞いたのだが、EUは「研究」を広くサポートするが、その対象はプロジェクトの派生物になるものに厳密に縛られ、プロジェクト内で上のStep 4と同じことはできない。国から博士課程の学生の予算が出るような場合あまり障害はないが、プロジェクト予算からのサポートに学生が依存してしまうような国では、第一線で活躍できる研究者を育てるのは難しくなる。

学生と起業

一風変わった決断がいるのは、教師が、博士課程の間に起業を志す学生とどうやって向き合うかだ。私の意見に賛成する人はあまりいないが、私は少なくとも、起業のアイデアがとんでもないものでなければ、学生は思い切って起業すべきだと考えている。私の考えでは、Ph.D.を取ることや、研究の世界に入ることには確かに価値があるが、しかし、それは考え得る最大の価値ではない。起業は学位論文よりより大きなインパクトを我々の生活に及ぼし得る。それに、起業してビジネスを成功させる機会をここで逃してしまえば、より多くの機会を逃してしまうことになる。もし起業がうまくいかなくても（たいていの場合そうだが）、学生にとっては数年を失うだけで、やろうと思えば博士課程を再開することもできる。

Sergey Brinは私にPh.D.プログラムをやめるかどうか相談することなくGoogleを立ち上げたが、もし聞かれていたとしたら、起業するように言っていただろう。別の学生、Anand Rajaramanは起業に関して私にアドバイスを求めてきた。彼は、あと半年で卒業というところだったが、私は、大学を出てJungleeの創始者になるように彼に言った。そのベンチャーは大成功し、数年後、彼はスタンフォードに戻ってきて、まったく新しい論文のテーマに取りかかった。それは、彼がJungleeで学んだことの一部を集約したものであり、そして彼はDr. Rajaramanとなった。

起業について考えるのにシリコンバレーにいる必要はない。良いアイデアはどこでも生み出すことができるし、良い先生なら、必要に応じて、学生の研究がベンチャー企業の土台になるかも、という選択肢を提示してくれるだろう。私は、別の大学のとある学生から来たメールをよく覚えている。「学位論文になってかつ役に立つ研究というのはあり得ますか？」と。私が肯定的に返事をしたところ、「うちの先生にそのことを説明してくれませんか」と頼まれたのだ。その先生は結局、学生に良いサービスを提供できていなかったと言える。その指導方針がごく一般的なものであったにも関わらずだ。この文章を手直ししている最中でさえ、私は、技術的な研究が、たとえ商用化できなかったとしても、やる価値があると認められるべきだという考えに行きついた。

後記

私のキャリアでの様々な仕事のうち、私が最も誇りに思うのは、53人のPh.D.コースの学生と、それに続く弟子たちだ。(http://infolab.stanford.edu/~ullman/pub/jdutree.txt と、この記事の最初の写真を参照。）その多くが、私には絶対にできなかったようなことを、驚くぐらいよくやってくれた。そして、それぞれが独自の才能を分野で発揮し、眺めているだけでもよい勉強になった。彼らの成功に私が貢献したと思いたいものだが、私がしてあげたと言えるたった１つのことは、彼らが自らの力で才能を開花できる道を遮らないようにした、ということだけだ。

著者

Jeffrey D. Ullman (ullman@cs.stanford.edu) is the Stanford W. Ascherman Professor of Computer Science (Emeritus) at Stanford University.

論文の先にあるもの

2009-04-01T13:18:00.053+09:00

研究が論文を書いて終わりでないなら、こんな心配をする必要はないはず。

自明なことを述べた論文は掲載されない（中略）「原理が複雑であまり便利でないシステム」の方が論文として発表されやすくなってしまう

論文査読のシステムでは、確かに、査読者のめぐりあわせ次第で、重要な技術でも適切に評価されないことがある。けれど、もし本当に便利でないのならば、将来的に引用されることもなく、実用化もされず、論文の海の中に埋没するだけではないだろうか。

本当に便利なものだけを学会・論文誌に載せたい心情は理解できるが、実際、技術の本当の便利さがわかるのは、研究の結果が世に出てからのこと。つまり、便利さや将来的な世の中へのインパクトというのは、未来に起こる話であって、研究成果を発表する時点でそれを実証せよというはなんとも酷なように感じる。

（査読で便利なシステムを取り上げられない）問題を解決するのは簡単で、論文の発表とその評価を分けてしまえば良い。論文を書いたらすぐそれをWebにアップし、読者に評価をまかせてしまうわけである。

Google Scholarで調べられるような論文の引用数や、ビジネスなどへの実用化という観点からみると、現行の査読システムでも、既にこの機能はうまく働いているように思う。最近では論文のダウンロード数なんて指標も使える。けれど、査読なしでオープン評価の方式を採った場合、著者自身が既にある程度注目を集めている人でないと、Webに公開しただけで読んでもらえたり、重要さを理解してもらうのは相当難しい。これでは、Webで目立つ人の論文ばかりが取り上げられ、「本当に便利な研究」を拾い上げる方向にはつながりそうもない。

増井さんのエントリには、おそらく無意識のうちに、研究のゴールを「論文を学会・論文誌で発表すること」に据えている様子が見え隠れする。(増井さんは、本棚.orgなどのサービスを動かしていたりと、論文を書いた後の実用性までちゃんと意識していることはよくわかるのだけれど）

世の中への貢献を意識せず、「論文を書けば、誰かが読んでくれるだろう」という姿勢でいることは、研究者、特に、これから研究の道を志す博士課程の学生にとって、とても不幸なことに思う。世の中との接点をないがしろにしたまま研究をしてるいると、いつしか研究に注ぎ込んだ時間の意味を見失い、もし論文が採録されなければ、自分の仕事への自信、価値判断が崩壊しかねない。

研究の「便利さ」が見出されるのは、近い未来かもしれないし、もっと長くて何十年後かもしれない。それでも、自分の研究の成果が、どのように世の中にインパクトを与えることができるかを考え、そしてそれを一番理解してくれる、あるいは実用化につなげてくれる環境に身を置くことが、研究へのモチベーションの維持するためにも、さらには研究を埋没させないために最も大事なことだと思う。

もちろん、研究成果を論文にすることにはとても価値があるのだけれど、それが考えられる「最高」の価値ではないことも知っておくべき。論文を発表するより、実際に起業して研究成果をサービスにして世に送り出す方が、世の中にはるかに大きなインパクトを与える可能性があるから。

（研究に関するこの話題については、実例を含めたよい話があるので、後日紹介します。追記：この記事です Leo's Chronicle: Ullman先生からのアドバイス)

プログラマは世界をこう視る

2009-03-26T13:32:00.020+09:00

プログラマが普段どのように問題と向き合あっているかを知るのに、これはうってつけ。

「プログラマのための論理パズル～難題を突破する論理思考トレーニング」

今回、縁があってこの本の出版のお手伝いをさせていただきました。内容はやや難し目のパズル問題集。すべての問題に目を通して、紙と鉛筆で解けるものもあれば、実際に手を動かしてプログラムを書いてみたり。前半は、プログラマでない人でも取り組めるようになっていますが、お勧めは実際にプログラムを使って解く後半。

プログラミングコンテストに挑んだことのある人には、もうおなじみの考え方だと思います。普通の人間ならやらないけれど、コンピュータというお供がいると、すべての可能性を調べ上げるような愚直な方法でも着実に実行してくれる。その様子を見て、人間がより良いアルゴリズムを思いつく、というサイクルが問題を通して学べます。

例えば「数独」。日本では、紙と鉛筆で解くパズルの代表例になっていますが、プログラマの手にかかると、コンピューターを使った答えの探索問題に早変わりです。

原著者のDennis Shasha先生も以下のように述べています。

授業中、私は、いわゆる“講義” をほとんどしない。その代わり、パズルを解くテクニックを披露する。問題の“解答” ではなく、“解法” を紹介するのだ。（中略）面白いことに、学生たちはその週の授業を終えると、自分の問題解決能力が向上していることに驚く。授業を通して得られた体験が、現実問題への取り組み方の一部なのだ。

現実の問題にどう取り組むかを、パズルを通して学ぶ。そのような「プログラマの視点」を垣間見られる例を挙げるとするなら、たとえば、Googleが膨大なデータを扱うために開発したMap-Reduceという計算フレームワーク。その仕組みは説明するととても簡単（問題を分割して解いて、後でまとめるだけ）ですが、それを生みだしたベースとなる物事の見方が、まさに「プログラマの視点」なのです。

こればかりは考え方（Shasha先生の言う「解法」）を知らないと、なかなか０からは出てこないものなので、既にプログラマの人にも、これからプログラミングを始める人にも、お勧めの１冊です。

(補足）

すでにこういった考え方に親しみのあるプログラマにとっては、後半より、前半のパズル問題の方が難しくて手ごたえがあると思います。腕に覚えがある方は、頭のトレーニング用にもどうぞ。

子どもはどこにいるの？

2009-03-13T10:21:00.041+09:00

（最初に）長文です。そして、このエントリ、特に後半部分は、むしろ今「親」になっていない人、あるいは、子供に手がかからなくなってきた人に読んで欲しいと思っています。

「研究している間、子どもはどこにいるの？」研究に限らず、夫婦共働きなどでも気になるこの話。ボストンに留学中のtsugo-tsugoさんに、アメリカでの様子を教えてもらいました。（アメリカは州によってぜんぜん法律が違うことは念頭に置いて読んでください。）

マサチューセッツ州の場合、14才以下の子供だけを家においておくのは幼児虐待とみなされ、それに気づいた周囲の人には通報義務があります。ということで、周囲の話を聞いてる限りでは、子供の保育園、学校がない時間帯はベビーシッターを雇うか、常に家に両親どちらかがいるはずです。ベビーシッターは、教会や大学、近所のコミュニティ等で近所の学生等を紹介してもらう無認可のサービスが多いです。

法律の縛りが社会に与える影響は大きい。需要が生まれ、供給体制もできてくる。今の日本だと、子育てのためにどちらか片方（9割以上母親）が仕事・キャリアをあきらめてる、という状況ではないでしょうか。そしてそれが当然という風潮がある（3歳までは母親が～云々、とか）。ちなみに学童保育は学年の途中までということも多いので、両親共働きの家庭では、まだ小学生の子どもが一人で誰もいない家に帰ることになります。これを国（州）として是とするかどうか。この法律には、明確にNOというメッセージが表れています。

大学の先生の場合、わりあい自分のスケジュールを自由に調節できるのと、アメリカは家族の用事で休むのは当然、という文化があるので、結構フレキシブルにやっている印象。子供が病気になったので、東海岸に単身赴任している旦那さんが育休をとって西海岸まで飛んでいく（！）、という話も聞いたことはあります。わりあい男女関係なく育児にかかわっている、というよりもそうしないとやっていけない印象があります。

アメリカでも研究者同士で夫婦別居せざるを得ない場合も多いようなので、必ずしもアメリカが理想郷というわけでもありません。一方、日本にいる僕の周りでは、子どもの保育園や小学校関係の保護者会などで、お父さんが参加しているのを目にすることはほとんどありません。周りはお母さんばかりで、参加している男性は僕一人というケースがほとんど。紅一点ならぬ青一点（？）。仕事が終わって（終わらせて）から、スーツ姿で駆けつけるお母さん達はほんとうに偉いと思います。

あとは中国出身の研究者の場合、出身地によっては子供は2、3歳ぐらいまで母親方の両親が育てる風習があります。その場合、母親方の祖母がビザを取ってアメリカまで出向いてきたりします。

これだと保育園に入れなかったとしても、なんとかやっていけそうです。おじいちゃん、おばあちゃんが家にいて面倒を見てくれる。それがたとえ週に1日とか、子どもが病気のときだけだとしても大変ありがたいことです。けれど、改めて考えみてほしいのは、昼間の子どもをちゃんと見てもらえるというのは、実は既に相当の「溜め」がある状況なのです。

「溜め」のある社会へ

この「溜め」という言葉は湯浅誠さんが、お金の多寡だけではない「貧困」の様子を表現するために使っている言葉です。（「生きづらさ」の臨界―“溜め”のある社会へを読むと、今の日本では、本当に紙一重の差で「溜め」がなくなってしまうことがよくわかります。）

人間は“溜め”に包まれており、大きい人も小さい人もいるが、お金の“溜め”、親や親戚など人間関係の“溜め”、自分に自信がある精神的な“溜め”。全体としてそういうものが失われるのが貧困である

子どもを育てながら研究や仕事を続けられるのも、なんらかの「溜め」があるから。この「溜め」に自覚がなく、仕事がない人に「高校、大学などに行って手に職をつけなかったのが悪い」「私は頑張ったからできた」という類の発言を無邪気にしてしまうと、「溜め」を持たない人にどうしようもない絶望感を与えてしまいます。「自己責任」で済ませるにはあまりにも重い話です。例えば、「勉強する環境があった」、そして、「無事に大学に通うことができた」というのも立派な「溜め」です。経済的、家庭の事情で諦めざるをえなかった人もいるし、勉強に必要な「親の理解」「心の余裕」があるかどうかも「溜め」になることがわかってきています（後述する「子どもの貧困」に関連）

中国での、祖父母が孫の面倒を見るという慣習は、キャリアを確立する20代～30代の大事なときに「溜め」を作るのに有効に働いているように思います。女性研究者なら、ちょうど子育てと、テニュアトラックに入る時期が重なります。tsugo-tsugoさんのエントリで紹介されている出産後すぐに研究を始める女性研究者たちの気持ちは、十分察してあげるべきでしょう。

残念ながら今の日本に、子供を持つ人のキャリア形成を支援する「溜め」が十分あるようには思いません。核家族化が進んでいるのは、僕が小学生のころ（20年以上前）から社会科で教わっているような話です。昼間こどもを見てくれる親や祖父母は後から作れないし、自分でいきなり保育園を作るわけにもいかない。既存の保育園は、既にキャリアや仕事がある人でないと、定員がいっぱいで入れず、手に職をつけるための勉強や、就職活動すらできなくなります。不況でパートナーの稼ぎが減少し、いざ自分が新たに仕事を見つけようとしても、資格やキャリアがないために仕事を見つけるのが難しく、この「溜め」のなさを痛感している人はさらに多くなったことと思います。

子育て支援は保育園だけでは全然足りない

子どもが幼いときは、一週間ずっと高熱をだして保育園では預かってもらえないなど、仕事を休まざるを得なくなるときがかなりの頻度であります。（病気のときは基本的にベビーシッターさんも使えません）。核家族、共働き、病児保育もないという環境で、頻繁に仕事を休んで、果たして仕事を失わない、キャリアを傷つけずに済むと断言できるでしょうか？

「溜め」を作るには、会社側の子育てへの理解も必要です。先に述べた母親ばかりの保護者会。これはお父さんがさぼっているから？（というのもけっこうあると思います。そんなお父さん達は要反省。）それだけでなく、こどもの面倒をみられる時間に仕事を終わらせること、そしてそれが、「溜め」を作るのに必要なのだという意識が会社や上司の中にも必要です。それがないと、お父さんが職場にとられてしまいます。東大でも、会議は5時までと決めたようですが、これは評価すべきことだと思います。

東京大学は３日、新年度から、原則、午後５時以降の公的な会議を行わないことを決めた。この日定めた「男女共同参画加速のための宣言」の中の一項で、教員に、仕事と生活のバランスを考えてもらい、特に女性研究者の活躍を促すのが狙いだ。・・・
http://www.asahi.com/national/update/0304/TKY200903030308.html

ただし、この目的を「女性がいるから」とするのは大きな間違い。お父さん方も早く自宅に帰れるようにしないと、子供の面倒を見る余裕という「溜め」がない人はさらに「溜め」を失い、社会から取り残されていく。そして、その影響は世代をまたがって固定化していきます。子どもの貧困―日本の不公平を考える、では、親のそういった心の余裕という「溜め」や、さらには学歴までもが、子供の将来における収入に影響を及ぼすというデータを示しています。子どもの「貧困」とはなにか、そしていかに多くの日本の子供が、まさに今「貧困」状態にありながら、そこから抜け出せなくなっているかが、詳細な分析結果とともに述べられています。

子どもを助けようとするなら、親を助けよ

この「溜め」の問題で隠れているのは、「溜め」がないことで、大学や仕事などのキャリアをあきらめてしまった人は、もう「溜め」がない人とすらカウントされないという事実。キャリアを目指せる環境が整うなら目指したい（これが需要になる）のに、到底かなわないと最初から諦めてしまっている人は、需要としては決してカウントされない。小泉政権下で、保育園の待機児童の定義の分母をすり替えて、待機児童の割合を少なく見せるトリックをしたのと同じです。

2002年（平成14年）4月から国は、待機児童の定義を変えた。認可外の保育所に入っている児童の内、自治体が助成金を出している保育所にいる児童は、待機児童から外すことにしたのである。つまり今後は、認可保育所に入所を希望していても、自治体独自の保育の取り組みや、幼稚園の預かりシステムなどで、一時的にお世話になっている児童は、待機児童としてカウントされなくなったわけだ。
http://www.sensenfukoku.net/policy/ninsyo/index.html

保育園に預けて働きたい、大学に通いたいのにそれができない人は、待機児童数が示すよりもたくさんいるのです。日本では、「溜め」をつくるために親がキャリアを身につけようとすれば、親（特に母親）はこどもを優先すべきだからキャリアはあきらめろ、とでもいわんばかりの雰囲気があります。現に既に仕事（あるいは仕事に就く見込み）がないと保育園には入れません。仕事があっても年度途中から入るのは、かなり絶望的です。

教育や将来の収入などを見越した上で、本当の意味でこどもを大事にする、というのは、実はその親のキャリア形成を支援することに他ならないことを「子どもの貧困」という本は示唆しています。子どもを持つことがキャリア形成に不利に働く今の日本の現状では、本当に子供を大事にしていないのは、「親」ではなく、むしろこの日本という「国」や「社会」の方だと言わざるを得ません。それゆえ、病気のときにまで誰かしらに子どもを見てもらえるような、既に「溜め」のある人と、そうでない人との差は広がるばかりになります。これは月数万の補助で埋められるような「差」ではありません。

そして、この問題に気付くのは、たいていこどもが生まれた後です。そのときにはもう当事者であり、今の生活、仕事を守るのに必死なため、政治活動に一番参加しにくい立場になってしまいます。まずは、この問題意識を共有してくれる人を、政界だけでなく、学校や企業などの社会の中に生み出さないといけない。もはや「貧困」はホームレスだけの問題でないし、「子育て」も「親」になった人だけの問題ではない。「親」になってからでは遅いのです。

SIGMOD2009 Accepted Papers

2009-03-11T11:41:00.013+09:00

SIGMOD2009の採録論文が発表されました。そのうちのいくつかについて、タイトルだけから内容を推測。

Yahoo! Researchの"Generating Example Data for Dataflow Programs"は恐らくPig Latinのデバッグ用のサンプルデータ生成の話。Hadoopなどの上で、複雑なデータ構造を動的に組み立てていくプログラム書きながら、横に実行結果の例を「適切に」示したサンプルが表示されると、わかりやすいよね、という話。
”Towards a simpler XML Schema: effortless handling of nondeterministic regular expressions”はついに来たか、という感じ。Relational styleの考えが入っていて、スキーマ(relation)から考えられるいろいろな木構造をNFAを使って同時に検証する、という流れだったら嬉しい。
"DDE: From Dewey to a Fully Dynamic XML Labeling" 。XMLの索引づけはもう食傷気味なのですが。。。「Fully」といいつつ挿入・削除以外の更新操作（木の移動とか）をサポートしていないと、がっくりきそう。
その他、multi-core CPU(Dependency-Aware Reordering for Parallelizing Query Optimization in Multi-Core CPUs)とか、SSD(Query Processing Techniques for Solid State Drives)の話もちらほら。

圧巻は、64番 ”A Comparison of Approaches to Large Scale Data Analysis”。Brown, MIT, UW Madison, Yale、そしてMicrosoftって、どんだけコネクションが広いんだ、あなたたちｗ。日本がDBコミュニティで存在感が出せないのは、こういった人脈がないことに尽きると思います。

それにしても、"Why Not?"ってなんだろう？DBMSがこう検索したらどう？とでも聞いてくるのかな？"Schema-Free XQuery"のときといい、Jagadishたちのグループは、論文のネーミングが秀逸です。

全体としての印象は、シリコンバレーに集まっているラボが強い。Microsoft, Yahoo! Research, HPなどなど。もともとはMITやStanford出身だったりするのですが。Stanfordもシリコンバレーの大学。

今回のSIGMODでは、僕は勝負すらできなかったので、投稿して落とされるよりたちが悪い。大負けです。悔しい。

23
Entity Resolution with Iterative Blocking
Steven Whang*, Stanford University
David Menestrina, Stanford University
Georgia Koutrika, Stanford University
Martin Theobald, Stanford University
Hector Garcia-Molina, Stanford University
25
Dependency-Aware Reordering for Parallelizing Query Optimization in Multi-Core CPUs
Wook-Shin Han*, Kyungpook National University
Jinsoo Lee,
38
Minimizing the Communication Cost for Continuous Skyline Maintenance
Zhenjie Zhang*, National University of Singapo
Reynold Cheng,
Dimitris Papadias, HKUST
Anthony K. H. Tung, National University of Singapore
47
FlexRecs: Expressing and Combining Flexible Recommendations
Georgia Koutrika*, Stanford University
Benjamin Bercovitz, Stanford University
Hector Garcia-Molina, Stanford University
64
A Comparison of Approaches to Large Scale Data Analysis
Andrew Pavlo*, Brown University
Samuel Madden, Massachusetts Institute of Technology
David DeWitt, Microsoft
Michael Stonebraker, Massachusetts Institute of Technology
Alexander Rasin, Brown University
Erik Paulson, University of Wisconsin-Madison
Lakshmikant Shrinivas, UW-Madison
Daniel Abadi, Yale University
69
GAMPS: Compressing Multi Sensor Data by Grouping and Amplitude Scaling
Sorabh Gandhi, University of California, Santa Barbara
Suman Nath*, Microsoft Research
Subhash Suri, UCSB
Jie Liu,
94
Authenticated Join Processing in Outsourced Databases
Yin Yang, HKUST
Dimitris Papadias*, HKUST
Stavros Papadopoulos, HKUST
Panos Kalnis, NUS
115
Privacy Integrated Queries: An Extensible Platform for Privacy-Preserving Data Analysis
Frank McSherry*, Microsoft
118
Query Simplification: Graceful Degradation for Join-Order Optimization
Thomas Neumann*, Max-Planck-Institut Informatik
119
Scalable Join Processing on Very Large RDF Graphs
Thomas Neumann*, Max-Planck-Institut Informatik
Gerhard Weikum, Max-Planck-Institut Informatik
120
Combining Keyword Search and Forms for Ad Hoc Querying of Databases
Eric Chu*, University of Wisconsin-Madiso
Akanksha Baid, University of Wisconsin-Madison
Xiaoyong Chai, University of Wisconsin-Madison
AnHai Doan, Univ of Wisconsin
Jeff Naughton, University of Wisconsin
121
Attacks on Privacy and deFinetti's Theorem
Daniel Kifer*, Penn State University
122
Optimizing Complex Extraction Programs over Evolving Text Data
Fei Chen*, UW-Madison
AnHai Doan, Univ of Wisconsin
Jun Yang, Duke University
Raghu Ramakrishnan,
Byron Gao,
142
DDE: From Dewey to a Fully Dynamic XML Labeling
Liang Xu*, NUS
Tok Wang Ling, NUS
Huayu Wu, NUS
Zhifeng Bao, NUS
143
Self-organizing Tuple Reconstruction in Column-stores
Stratos Idreos*, CWI
Martin Kersten, CWI
Stefan Manegold, CWI
151
Ranking Queries on Distributed Probabilistic Data
Feifei Li*, Florida State University
Ke Yi, Department of Computer Science and Engineering, HKUST
Jeffrey Jestes, Computer Science Department, FSU
161
Generating Example Data for Dataflow Programs
Christopher Olston*, Yahoo! Research
Shubham Chopra, Yahoo! Research
Utkarsh Srivastava, Yahoo! Research
165
Secure Outsourced Aggregation via One-way Chains
Suman Nath*, Microsoft Research
Haifeng Yu,
166
ZStream: A Cost-based Query Processor for Adaptively Detecting Composite Events
Yuan Mei*, MIT
Samuel Madden, Massachusetts Institute of Technology
190
Serial and Parallel Methods for I/O Efficient Suffix Tree Construction
Amol Ghoting*, IBM Research
Konstantin Makarychev, IBM Research
191
Asynchronous View Maintenance for VLSD Databases
Parag Agrawal, Stanford University
Adam Silberstein, Yahoo! Research
Brian Cooper*, Yahoo! Research
Utkarsh Srivastava, Yahoo! Research
Raghu Ramakrishnan,
195
Kernel-Based Skyline Cardinality Estimation
Zhenjie Zhang*, National University of Singapo
Yin Yang, HKUST
Ruichu Cai, School of Computer Science and Engineering, South China University of Technology
Dimitris Papadias, HKUST
Anthony K. H. Tung, National University of Singapore
207
Quality and Efficiency in High Dimensional Nearest Neighbor Search
Yufei Tao*, CUHK
Ke Yi, Department of Computer Science and Engineering, HKUST
Cheng Sheng, The Chinese University of Hong Kong
Panos Kalnis, National University of Singapore
224
Continuous Obstructed Nearest Neighbor Queries in Spatial Databases
Yunjun Gao*, Singapore Management Univ.
Baihua Zheng, Singapore Management Univ.
235
Keyword Search in Databases: The Power of RDBMS
Lu Qin*, CUHK
Jeffrey Xu Yu, The Chinese Univ. of Hong Kong
Lijun Chang,
242
Why Not?
Adriane Chapman*, MITRE Corporation
H.V. Jagadish, Univ. Michigan
244
Dictionary-based Order-preserving String Compression for Main Memory Column Stores
Carsten Binnig*, ETH Zurich
Stefan Hildenbrand, ETH Zurich
Franz Frber,
245
ROX: Run-time Optimization of XQueries
Riham Abdel Kader*, University of Twente
Peter Boncz, CWI
Stefan Manegold, CWI
Maurice Van Keulen, University of Twente
253
An Architecture for Recycling Intermediates in a Column-store
Milena Ivanova*, CWI
Martin Kersten, CWI
Niels Nes, CWI
Romulo Goncalves, CWI
266
Scalable Skyline Computation Using Object-based Space Partitioning
ZHANG Shiming, HKU
Nikos Mamoulis*, University of Hong Kong
David Cheung, University of Hong Kong
269
FlashLogging: Exploiting Flash Devices for Synchronous Logging Performance
Shimin Chen*, Intel Research Pittsburgh
292
Skip-and-Prune: Cosine-based Top-K Query Processing for Efficient Context-Sensitive Document Retrieval
Jong wook Kim*, ASU
K. Selcuk Candan,
293
Robust XPath Expressions for Web Extraction
Philip Bohannon, Yahoo! Research
Nilesh Dalvi*, Yahoo! Research
Fei Sha, University of Southern California
301
Incremental Maintenance of Length Normalized Indexes for Approximate String Matching
Marios Hadjieleftheriou*, AT&T Labs - Research
Nick Koudas, University of Toronto
Divesh Srivastava, AT&T Labs-Research
308
Top-k Queries on Uncertain Data: On Score Distribution and Typical Answers
Tingjian Ge*, Brown University
Stanley Zdonik, Brown University
Samuel Madden, Massachusetts Institute of Technology
316
Top-K Generation of Integrated Schemas Based on Directed and Weighted Correspondences
Ahmed Radwan, University of Miami
Lucian Popa*, IBM Almaden
Ioana Stanoi, IBM Almaden
Akmal Younis, University of Miami
319
E = MC3: Managing Uncertain Enterprise Data
Peter Haas, IBM
Fei Xu, University of Florida
Vuk Ercegovac*, IBM
Eugene Shekita, IBM
335
Estimating the Confidence of Conditional Functional Dependencies
Graham Cormode, AT&T Labs - Research
Lukasz Golab*, AT&T Research
Flip Korn, AT&T Labs - Research
Andrew McGregor, Microsoft Research
Divesh Srivastava, AT&T Labs-Research
Xi Zhang, SUNY Buffalo
343
Monitoring Path Nearest Neighbor in Road Networks
Zaiben Chen, The University of Queensland
Heng Tao Shen*, The University of Queensland
Xiaofang Zhou, University of Queensland
Jeffrey Xu Yu, The Chinese Univ. of Hong Kong
347
Uncertainty Management in Rule-based Information Extraction Systems
Eirinaios Michelakis*, UC Berkeley
Peter Haas, IBM
Rajasekar Krishnamurthy, IBM
Shivakumar Vaithyanathan, IBM
359
Approximate Entity Extraction with Edit Constraints
Wei Wang, University of New South Wales
Chuan Xiao*, UNSW
Xuemin Lin,
Chengqi Zhang, UTS, Australia
361
Secure k-NN Computation on Encrypted Databases
Wai Kit Wong*, The University of Hong Kong
David Cheung, University of Hong Kong
Ben Kao, The University of Hong Kong
Nikos Mamoulis, University of Hong Kong
364
Query Processing Techniques for Solid State Drives
Dimitris Tsirogiannis*, University of Toronto
Stavros Harizopoulos, HP Labs
Mehul Shah, HP Labs
Janet Wiener, Hewlett-Packard Laboratories
Goetz Graefe, HP Labs
385
Query by Output
Quoc Trung Tran*, NUS
Chee-Yong Chan,
Srinivasan Parthasarathy, Ohio State University
387
Exploiting Context Analysis for Combining Multiple Entity Resolution Systems
Zhaoqi Chen*, UCI
395
Towards a simpler XML Schema: effortless handling of nondeterministic regular expressions
Geert Jan Bex, Hasselt University
Wouter Gelade*, Hasselt University
Wim Martens, University of Dortmund
Frank Neven, Hasselt University
399
Cost Based optimization and plan selection for XPath
Haris Georgiadis*, AUEB
Minas Charalambidis, AUEB
Vasilis Vassalos, AUEB
400
Core Schema Mappings
Giansalvatore Mecca*, Università della Basilicata
Paolo Papotti, Università di Roma Tre
Salvatore Raunich, Unversità della Basilicata
403
A Gauss Funtion based Approach for Unbalanced Ontology Matching
Qian Zhong, Tsinghua University
Hanyu Li*, IBM CRL
Juanzi Li,
Guo tong Xie, ibm
Jie Tang,
Lizhu Zhou, Tsinghua University
407
Efficient Type-Ahead Search on Relational Data: a TASTIER Approach
Guoliang Li*, Tsinghua University
Shengyue Ji, UC Irvine
Chen Li, Univeristy of California, Irvine
Jianhua Feng, Tsinghua University
493
A Revised R*-tree in Comparison with Related Index Structures
Norbert Beckmann, University of Marburg
Bernhard Seeger*, University of Marburg
495
Indexing Correlated Probabilistic databases
Bhargav Kanagal*, University of Maryland
Amol Deshpande, University of Maryland, college Park
505
Efficient Incorporation of User Feedback into Information Extraction and Integration Programs
Xiaoyong Chai*, University of Wisconsin-Madison
Ba-Quy Vuong, Univ. of Wisconsin at Madison
AnHai Doan, Univ of Wisconsin
Jeff Naughton, University of Wisconsin
513
Extending Autocompletion to Tolerate Errors
Surajit Chaudhuri, Microsoft Research
Raghav Kaushik*, Microsoft Research
526
Privacy Preservation of Aggregates in Hidden Databases: Why and How?
Arjun Dasgupta*, University of Texas Arlington
Nan Zhang, George Washington University
Gautam Das, Univ of Texas at Arlington
Surajit Chaudhuri, Microsoft Research
534
A Declarative Data Representation Framework
Arvind Arasu*, Microsoft Research
Raghav Kaushik, Microsoft Research
553
Secondary-Storage Confidence Computation for Conjunctive Queries with Inequalities
Jiewen Huang, Oxford University
Dan Olteanu*, Oxford University
562
3-HOP: A High-Compression Indexing Scheme for Reachability Query
Ruoming Jin*, Kent State University
Yang Xiang, Kent State University
Ning Ruan, Kent State University
Dave Fuhry, Kent State University
565
A Framework for Testing Query Transformation Rules
Hicham Elmongui, Purdue University
Vivek Narasayya*, Microsoft Research
Ravi Ramamurthy, Microsoft Research
568
Robust and Efficient Algorithms for Rank Join Evaluation
Jonathan Finger, University of California Santa Cruz
Alkis Polyzotis*, UC Santa Cruz
569
Cross-tier, Label-based Security Enforcement for Web Applications
Brian Corcoran*, University of Maryland
Michael Hicks, University of Maryland
Nikhil Swamy, Microsoft Research
583
Optimizing I/O-Intensive Transactions in Highly Interactive Applications
Mohamed Sharaf*, Univ. of Toronto
Cristiana Amza, UofT
Panos Chrysanthis, University of Pittsburgh
Alexandros Labrinidis, University of Pittsburgh
585
Detecting and Resolving Unsound Workflow Views for Provenance Preservation
Peng Sun, Arizona State University
Ziyang Liu*, Arizona State University
Susan Davidson, University of Pennsylvania
Yi Chen, Arizona State University

イラストで知る研究の世界とその醍醐味

2009-03-10T10:06:00.042+09:00

研究の世界の雰囲気や、その面白さがどこにあるかご存じな方はとても少ないことと思います。

例えば大学4年で卒業し就職してしまうと（法学部や経済学部に多い）全くといっていいほど研究の世界を知らないまま社会に出ることになります。日本では、報道などのメディアに就職する方も学部卒ということが多いため、テレビ・新聞などで研究の世界について深く書かれた記事を目にする機会はほとんどありません。

NHKのサイエンス・ゼロなどの番組で、研究者の様子を垣間見ることもできます。しかし、番組は研究の世界の一側面を見せているだけであり（取材時間に比べてカットが多く、内容も製作者の主観に左右される）、研究の世界で活躍していて評判の高い人は、実はほとんどメディアにでてこない事情もあります（「21歳からのハローワーク（研究者編）」を参照）。そのような研究者は、論文という形で一生懸命アウトプットを出しているのですが、論文は学部教育や大学院、博士での研究トレーニングを経ないと読みこなせない（研究の内容だけでなく、意義すら理解できない）ため、学者間にとっては非常に価値のあることでも、一般の人にとっては無用の長物に見えてしまうことも少なくないのです。

そのように謎に包まれた研究の世界の様子を、tsugo-tsugoさんが、イラストを通して伝えてくれています。研究の面白さや、研究の進め方の本質をしっかりとらえていて、一部に根強いファンがつく人気ぶりです。僕もtsugo-tsugo劇場と勝手に名付けて、連載を楽しんで読んでいます。以下のリンク先からどうぞ。

研究を視覚化してみる（問題という山に登るか、解決するための道路を作るか）
Re:研究を視覚化してみる（どはまりの沼には要注意）
研究が面白い理由(1) （研究者はスーパーマン？）
研究が面白い理由(2) （思索の部屋に光がさす静かな感動）
研究が面白い理由(3)数学の重要性（研究者は魔法使い・科学のカッコよさはここにあり）
各分野間のつながり（「美しいは正義」の理論、理論から道具を作るのは「水面下の白鳥」、道具を使いこなす「魔法使い」。研究の世界もいろいろです）
データは主食（データは研究者の主食。その解析は若いうちの仕事？出世すると結果だけ欲しがる？）
闇夜を照らすPerspective Beam（結果だけ横取りしていたかに見えた教授陣にも、実は驚異的な能力が…。上手なプレゼンテーションをするには、この能力が欠かせない）
語りかける論文　（良く書かれた論文は、まるでレクチャーを受けているかのように読める）

こんな感じのかわいいイラストで、研究の世界に流れる感動や空気、驚きや醍醐味などをよく伝えてくれています。

ただし、一つだけ注意。tsugo-tsugoさん本人もおっしゃっているとおり、実際の研究は、かわいいばかりでなく結構殺伐としていることが多いです。博士課程では論文という形で成果が出せないと鬱になりがちです（学生相談所には博士課程の学生の相談が多いとか）。それに、日本では、ポスドク以外のアカデミアのポストにつける博士の割合は3割以下でもあります（H20年度の統計で、1万人の博士課程修了者のうち大学教員になった割合は23%、その他の研究者になったのは26％です）。研究の世界に飛び込むときは、実際の雰囲気に加え、社会の現状を知った上で入るのが望ましいと思います。

参考：
これから研究をはじめる人へのアドバイス（研究の世界の厳しさ。だたし、研究する力はアカデミアだけのものではない、という話）
科学者としてこの先、生き残る方法（小町さんによる記事。このブログのエントリも紹介されています）

テレビなどのメディアで紹介されていて分野に興味を持ったから、というのも悪くはありませんが、実際の研究現場と想像していた雰囲気のギャップに苦しむことがあります。例えば、一時期、精神鑑定がはやって精神科医を志す人が増えたけれど、プロファイリングなどの言葉でテレビで華々しく紹介されているのとは違い、現実はかなり地道な調査が要求される分野だそうです。（そもそも疾患者数が少なく、統計的に有意な結果が見出しにくいため、健常者にまで外挿した質問肢調査から病気の傾向を見出すSchizotypyのような研究が必要だったり）

参考:
教授からのメッセージ　（研究者という道について厳しく書かれています。しかし、実際これくらいの心づもりで闘争心を持って研究に臨んでいかないと、とても大成できないので、実は愛情たっぷりのお話）

研究の世界を知るには、実際に研究室を覗いてみたり、中に入って話を聞いたり、扱っているテーマに関して勉強して手を動かしてみるのが一番だと思います。僕自身、そうやって志望する研究室を変えた経験がありますし、自分が勉強したい分野と、実際にその研究が肌にあうかどうかは意外に異なるので、例えさわりだけだとしても、経験してみることが大事です。

研究テーマをベースに選ぶとしても、例えば生物学なら、対象が生物ではあることは常に変わらないけれども、実際に用いる研究手法は、測定機械、実験設備の有無、さらには特定の分野に強い人がいるかどうか、などという様々な事情で変わってきます。人の入れ替わりも激しい世界なので、5年、10年以上と同じテーマの研究を続けているラボは珍しいくらいです。ただ、研究の軸が一本通っていれば、それを元にいろいろな理論、手法、解析に手を出していける強みもあります。僕の場合は「データベースシステムを作ること」が研究の軸にあります。今現在は、ちょうど生物情報という融合分野にいますが、生物でも、情報系でも、そのアプリケーションは違えど、研究の目的自体にあまり違いはありません。

これからの研究の世界に飛び込む人には、酸いも甘いも知った上で臨んでほしい、という思いをこめて。

PODS 2009: Accepted Papers

2009-03-03T14:44:00.009+09:00

今日発表されました。

今年のPODS2009は面白そうです。XML関連の研究もまだまだ盛ん。研究の世界ではやりの、Uncertain dataは多くなってきていますが、それだけでなく、heavy-hitterとか、secondary indexingとか、DBのcore技術寄りの論文もあるみたいで、論文が出てくるのが楽しみです。

採録された中には、日本人（面識はないのですが天野さんという方）も一人。Libkinのラボにいるのですね。おめでとうございます。こうやって日本からデータベースコミュニティの中で活躍していけるようになる人が増えるとうれしいですね。


29 Dynamic Indexability: The Query-Update Tradeoff for One-Dimensional Range Queries
(Ke Yi)

31 Satisfiability of the downward fragment of XPath with data equality tests
(Diego Figueira)

37 Satisfiability and relevance for queries over active documents
(Serge Abiteboul, Pierre Bourhis and Bogdan Marinoiu)

38 Equivalence of SQL Queries In Presence of Embedded Dependencies
(Rada Chirkova and Michael Genesereth)

58 Distributed XML Design
(Serge Abiteboul, Georg Gottlob and Marco Manna)

59 Relationship Privacy: Output Perturbation for Queries with Joins
(Vibhor Rastogi, Michael Hay, Gerome Miklau and Dan Suciu)

63 Size and Treewidth Bounds for Conjunctive Queries
(Georg Gottlob, Stephanie Lee and Gregory Valiant)

65 A General Datalog-Based Framework for Tractable Query Answering over Ontologies
(Andrea Cali, Georg Gottlob and Thomas Lukasiewicz)

67 Optimal Tracking of Distributed Heavy Hitters and Quantiles
(Ke Yi and Qin Zhang)

69 Indexing Uncertain Data
(Pankaj K. Agarwal, Siu-Wing Cheng, Yufei Tao and Ke Yi)

71 Equivalence of Nested Queries with Mixed Semantics
(David DeHaan)

76 Running Tree Automata on Probabilistic XML
(Sara Cohen, Benny Kimelfeld and Yehoshua Sagiv)

78 XML with Incomplete Information: Models, Properties, and Query Answering
(Pablo Barcelo, Leonid Libkin, Antonella Poggi and Cristina Sirangelo)

79 XML Schema Mappings
(Shunichi Amano, Leonid Libkin and Filip Murlak)

82 XPath Evaluation in Linear Time with Polynomial Combined Complexity
(Pawel Parys)

89 Relative Information Completeness
(Wenfei Fan and Floris Geerts)

94 An Efficient Rigorous Approach for Identifying Statistically Significant Frequent Itemsets
(Adam Kirsch,  Michael Mitzenmacher, Andrea Pietracaprina, Geppino Pucci, Eli Upfal and Fabio Vandin)

98 Generalized Schema-Mappings, From Termination To Tractability
(Bruno Marnette)

103 Similarity Caching
(Flavio Chierichetti, Ravi Kumar and Sergei Vassilvitskii)

105 Optimal Sampling from Sliding Windows
(Vladimir Braverman, Rafail Ostrovsky and Carlo Zaniolo)

111 Exceeding Expectations and Clustering Uncertain Data
(Sudipto Guha and Kamesh Munagala)

116 Consensus Answers for Queries over Probabilistic Databases
(Jian Li and Amol Deshpande)

118 Computing All Skyline Probabilities for Uncertain Data
(Mikhail Atallah and Yinian Qi)

119 Reverse data exchange: coping with nulls
(Ronald Fagin, Phokion Kolaitis, Lucian Popa and Wang-Chiew Tan)

134 Space-optimal Heavy Hitters with Strong Error Bounds
(Radu Berinde, Graham Cormode, Piotr Indyk and Martin Strauss)

143 Secondary Indexing in One Dimension: Beyond Btrees and Bitmap Indexes
(Rasmus Pagh and S. Srinivasa Rao)

Pondering Bug Tracking Systems

2009-02-09T12:36:00.020+09:00

As a programmer, I have many things to hack, but unfortunately I am not smart enough to remember everything to code after I slept. In the next morning, I usually forget some features to code. Bug Tracking System (BTS) is useful to keep remembering these tasks. Joel Spolsky also wrote an article about Bug Tracking Systems, and I totally agree with what he said; Bug tracking system is necessary to ship high quality code.

I am using Bug Tracking Systems, such as Bugzilla, Trac, etc. (and also their Eclipse plug-ins). Once they are properly installed in a server machine, they works correctly, and I know many projects use these tools to share bug & new feature lists.

However, their web interfaces are not fun to use; I have to input many things to post a bug or feature, such as priority of the bug, current program version, who to assign the task, etc. Almost all of them are unnecessary for writing code, and sometime I do not want share tribal tasks merely saying 'implement SomethingReader class', but without posting it, I might forget it due to some interruption of my work.

Because of these frustrations, I have recently switched to the Remember the Mlik (RTM) service to manage my bug & feature lists. RTM's AJAX-based rich web interface have some nice shortcut keys (e.g, 't' for a new task, 1, 2, 3 ... for selecting priorities), and with Google Gears installed on your browser, you can edit tasks while you are offline. As the name 'Remember the Mlik' indicates, RTM can be used to manage quite tribal tasks; you can simply post 'write this code and that' to RTM, while this message does not make sense for the other people, it is quite informative for 'me'.

Free from explaining what to do for other people has a great effect on accelerating daily programming productivity. I'm not saying 'BTS is unnecessary', rather I'm saying BTS is necessary for sharing bugs and features, but not for personal work management. Well-known BTSes have too rich features for the personal use. What I want to do is to take a memo at online using web interfaces I open every day, and Remember the Milk completely meets this demand.

Googleはコンピューターに損害を与える可能性があります

2009-01-31T23:58:00.006+09:00

Googleの検索結果に「このサイトはコンピューターに損害を与える可能性があります」と付くので、不思議に思っていたら、Googleのサイトそのものも損害を与える可能性があるそうで。

まぁ、それなら仕方がないか(笑)

正規表現に見切りをつけるとき

2009-01-27T10:49:00.055+09:00

Perl, Rubyなど手軽に使えるプログラミング言語に慣れてくると、あらゆるテキストデータの処理に正規表現(regular expression)を使ってしまいがちです。

けれど実は、正規表現の処理能力を超えるフォーマットというのが存在します。その典型的な例が、XMLやJSONのように、入れ子になったデータフォーマットです。

例えば、

(a, b, (c, d))
(a, b, (c, (d, e)))

というように、括弧がどんどん入れ子になっていく構造は、括弧のネストの深さを数えないと正しく解釈できません。正規表現でも、一番外側の括弧の対応をとらえるために、/\(.*\)/、/\([^)]*\)/ などとはは書けますが、常に正しい括弧の対応をとっているとは限りませんし、もしうまくいったとしても、さらに内部の括弧をとらえるために、外側の括弧を取り除き、また同様の正規表現を内部の文字列に対して繰り返して適用する必要があります。

そして問題なのが、

(a, (b, c)), d, (e, f)

という文字列の場合。/\(.*\)/という正規表現では、以下のように色のついた範囲を拾ってしまいます。

(a, (b, c)), d, (e, f)

正規表現では、このようにちょっとしたデータ構造すら上手く構文解析できません。したがって、正規表現だけで文字列を処理する場合は、何らかの方法で括弧が2重、3重にならないように工夫する必要があります。（あるいは括弧内を再帰的に処理するプログラムを書くなど。）バイオ系のデータフォーマットでも、この正規表現の能力の限界を知らないがために、正規表現で処理できない入れ子になったデータを平気で書いてしまう人が多いので、手軽に処理したい場合は要注意です。（他にも2重引用符で囲まれた文字列の扱いも、正規表現では面倒な例です）

構文解析

では、正規表現の能力を超えるデータはどう扱えばいいのか？一番のお勧めは、ANTLRを使って字句解析(lexer)、構文解析(parser)するプログラムを生成する方法です。一昔前なら、lex/yacc、flex/bison, JavaCCなどしか選択肢がなかったのですが、今は断然ANTLRが便利です。ここでは、JSONを例にとって説明します。以下は、JSONで書かれた配列の中に配列がある構造です。

[0, [1, 2]]

字句解析では、これを、

LBracket([), Number(0), Comma(,), LBracket([), Number(1), Comma(,), Number(2), RBracket(]), RBracket(])

というようにトークン（文字列の単位, lexer ruleとして記述）に分解していきます。そして、これらのトークンにマッチする文法（parser rule)を定義します（以下の例は、説明のために他のデータ型については省いて簡潔に書きました）

array: LBracket Value (Comma Value)* RBracket;
value: Number | array;

ここでは、括弧 [ ] の中に、ValueをComma(,)でつなげて複数個書けるルールを定義しています。Valueとしては、数字(Number)以外に配列(array)も使えるので、配列の中に配列があるような入れ子になったデータ構造もこれで解析できます。

参考までに、僕がANTLRで作成したJSONの文法を紹介します。ANTLRの記述を覚えるコストはかかりますが、1ページ分の記述量でJSONのように構文が複雑なものも処理できるようになります。以下に挙げるのは、ANTLRのリファレンス（英語）と、その背景にある理論の教科書で、コンピューターサイエンスの学科では講義によく使われていてどれもお勧めです。Aho, Ullman先生らのドラゴンブック第2版（Ullman先生の息子さんがCGで表紙を作ったとか）は読みごたえ十分ですし、Apel先生の本ではVisitorパターンの使いどころのような、実装に近い話題にも触れられていて読みやすいです。稲葉君絶賛のParsing Techniquesなどもあります。

構文解析の実践としては、ANTLRをダウンロードするとサンプルの文法がたくさん付いてくるので、それを真似して書くのも習得への早道かと思います。一度ANTLRで文法を書くと、Perl/Ruby/C/C#/Javaなどの言語用のlexer/parserを生成できるようになるので、どの言語を使っている人にもお勧めです。しかし、まだ日本語のリファレンスがないのが構文解析の敷居を高くしている原因でしょう。この記事が素晴らしき構文解析の世界への足がかりになればいいなと思います。

（実用上の補足）

正規表現の中に自己を含めて循環定義できるRubyやPerlなどの処理系なら、入れ子もなんとか処理できるみたいです。以下はPerlのコード例。(「詳細正規表現第3版」を参考にしました）


$str = "(a (b, c)), (d), (e, f)";
$paren = qr/\([^()]*(?:(??{$paren})[^()]*)*\)/;
while ($str =~ /($paren)/g) {
print $1, "\n";
}

実行結果

(a (b, c))
(d)
(e, f)

括弧のパターンにマッチすると、その都度中身の正規表現がlazyに変わっていくというトリッキーな技です。このような正規表現は以下に述べるような形式言語理論上の正規表現の定義には含まれないのでご注意あれ。ただ、Perlで処理できるとしても、二重引用符とか、様々な括弧の種類に対応するように再帰型正規表現を書いていくと、ANTLRのparser ruleを書くのと似た状況になるとは思います。(追記）Perl6のRulesという機能では、ANTLRのような文法定義を書けるとか！入れ子が必要なときは、これを使いましょう、ということですね。

(コンピューターサイエンス的な補足）

細かい話をすると、正規表現は文脈自由文法というクラスのサブセットで、入れ子の構造をもった文法は、文脈自由だけれど正規表現ではありません。これは、pumping lemmaを使って証明できます。情報系の学科なら、計算量理論などの講義で習うはず。オートマトンにスタックをつけたプッシュダウンオートマトン（文脈自由文法と同じ表現能力を持つ）なら、このような入れ子をうまく処理できます。このあたりの話は「計算理論の基礎」という教科書に丁寧に書かれてあって（大学院入試の勉強のときにかなりお世話になりました）、コンピュータサイエンスの基礎のうち、オートマトン、NP完全問題など計算量にかかわる部分について学ぶのに優れた本です。（最近は第2版もでているようですが、3冊に分かれてしまって少々買いにくくなってしまいました。分けた方が持ちやすいのかな？）

なぜIEはFirefoxより優れているか？

2009-01-14T09:51:00.004+09:00

Firefoxでこんなことできる？

(Diggで見つけました）

TOEIC990点より大事なこと

2009-01-13T09:51:00.027+09:00

ごめんなさい。タイトルは釣りです。TOEICは受けたことすらないので、990点がいったいどんなレベルなのか想像もつきません。ただ、「英語を使う」のが目的なら、そんな点数を上げるための努力はしなくていいだろうなとは思ったので、英語を使う、特に「話す」ための要点をまとめてみます。

この記事を書くきっかけとなったのは、「英語の発音」というエントリが注目を集めているのを見て。英語の発音を気にしている人が多いことに驚きました。

僕自身、国際学会などで海外に行く機会は年に何回かありますが、そこでのトークを聞くと、中国系の人、インド系の人、東南アジア系の人、ヨーロッパ系の人とで、それぞれ発音の仕方が全然違うことがわかります。中でもインド系の人の発音はあまりブレス音を使わないせいか、慣れないうちは本当に英語を話しているのか？と耳を疑うほどです。日本語の方言をイメージすると、この状況がわかりやすいと思います。東北弁などは、聞き慣れない人にとってはまるで外国語のように聞こえますよね。

発音は違えど、皆、英語という共通語を通して、コミュニケーションをとっている。ただ、方言と違うのは、使っている言葉は書いてみるとほとんど同じだというところ。論文など研究の世界の「普遍語」としての書き言葉を見るだけでは想像もつかないほど、実際の英語の発音の仕方は多様です。その様子を肌で感じると、「発音」などはさほど気にするべきことではなく、むしろ淀みなく話す「流暢さ」に重きを置く学習の方が、実践で役に立つことがわかると思います。

「発音」に関しては、日本の学校教育の中で触れられることがないのが不思議ですが、フォニックスという小学校低学年前後くらいの子供のための、英語の発音の学習法があります（親が英語教師だったので、子供の頃に教材で遊んでいました）。綴りと発音の関係、舌、息などをどのように使うか、ということを学び、以下の「英語、好きですか？アメリカの子供たちは、こうしてＡＢＣを覚えます」というフォニックスの本では、子供が読めるように発音についてやさしく丁寧に説明されています。簡単な内容ですが、それでも発音に関しては、この本で十分なことを学べると思います。

一昔前と違って、英語の音声はPodCastや、Talking Issuesなどでも、簡単に手に入るようになりました。もう、10年前とは時代がすっかり変わっていることに世の中も気付くべきでしょう。英語で授業ができなかったり、生の英語を聞き慣れていないためにカタカナ発音になってしまう英語の先生よりも、今やインターネットの方が相当いい先生になり得ます。生徒の方が先生よりも流暢な英語を話す、なんてことも十分あるので、先生のコンプレックスが、そんな生徒にぶつけられないことを祈るばかり。電子辞書もあるし、インターネットも辞書代わりになるので意味・用例を調べるのも簡単とは、なんていい時代！

そんな生の教材を使って、音声の後に続けて実際に声を出してみるシャドーイングを続けていくだけで、「話す」だけでなく「聞く」力もついてきます。これは、こどもの言葉の学習法と同じ。わからなくても、聞き取れなくても、とりあえず聞いたことを繰り返す。ただ、状況に応じた言葉を聞く機会が無い、というのが、日本で英語を学ぶ難しさではありますが。

そして「流暢さ」に必要なのは、お願いや質問の仕方、意見の言うときの決まり文句など、中学校の教科書に出てくるくらい簡単なフレーズが、口をついて出てくるかがポイントです。英語の学習用教材など、市販の本もいくつか漁ってみたのですが、難しい文章の読解向けで会話には役立たなかったり、単語、熟語の羅列で継続して学習するには飽きやすい本とか、会話用のテキストでもストーリーを重視しすぎてフレーズの絶対量が少ない、などそれぞれいろいろ難があります。そんな中で一番役に立ったのは「英会話 Make It!」という小さな本。

こんなことが言いたいのだけれど、英語で出てこない。そんなかゆいところに手が届く表現が状況ごとにまとめられているので本当に助かっています。慣用句など洒落た表現ではなく、2、3回繰り返して発音して練習するだけで、明日話すためにすぐ使える（くらい本当に基礎的な）フレーズを効率よく学べるのが良いです。

英語でディスカッションを始めて、言葉に詰まってしまう日本人を見ると、この本にあるくらい簡単な表現すら自分で話した経験がないのだろうな、といつも感じています。Whatで始まる質問ができない、とか。本当にそんな程度のことです。でも、それを自信を持って話せるのとそうでないのとで、会話が成立するかどうか、さらには、有益な情報を相手から引き出し、メッセージをきちんと相手に伝えられるかどうかが決まります。

まとめ

世界中でバラバラなんだから発音なんて気にしない。練習したければ、小学生から使えるフォニックス教材で発音の仕方を学んで、インターネット上の先生（ニュース、PodCastなど。自分の好きな話が良い）に倣ってシャドーイングを続けること
本当に簡単なフレーズを練習して、自分の意見を話したり、質問するときの英語に自信を持つこと。

これだけで、そこいらの東大生より確実に英語が上手に話せるようになります。。。（悲しいことに、これは本当の話です。でも、これが英語での会話を教えない（教えられない）日本の英語教育の現実）

Leo's Chronicle: 英語コンプレックスなんて些細なこと（もうちょっと上のレベルに達したときに感じる英語の壁について）
Leo's Chronicle: 良い論文を書くために知っておくべき５つのこと (論文を書くときには、英語力以外の要素も要るという話）

季節の風景 - 柏キャンパス -

2009-01-08T17:35:00.001+09:00

柏キャンパスにて撮影

ぜひ押さえておきたいデータベースの教科書

2009-01-07T22:07:00.024+09:00

先日のエントリで少し話したのですが、僕が在学していたときの東大にはデータベースを学ぶためのコースというものがありませんでした（DB関係の授業は年に１つか２つある程度。現在はどうなんだろう？）。そんなときに役だったのは、やはり教科書。読みやすいものから順に紹介していきます。（とはいってもすべて英語の本です。あしからず）

一番のお薦めは、Raghu Ramakrishnan先生 (現在は、Yahoo! Research) の「Database Management Systems (3rd Edition)」。初学者から研究者まで幅広く使えます。データベース管理システム（DBMS）の基本概念から、問い合わせ最適化、トランザクション管理など、これらを実装・評価するために必要な、「DBの世界での常識」が、丁寧な語り口でふんだんに盛り込まれています。この1冊を読んでおけば、DBの世界で議論するための土台が十二分に身に付きます。

2つ目は、StanfordからDB界を引っ張っている3人の先生、Hector Garcia-Molina、Jeffrey D. Ullman（Ullman先生は昨年に引退したのですが、まだラボに顔を出しているようです）、Jennifer D. Widom （世界1周旅行に出かけているらしい…）による「Database Systems: The Complete Book」。これもRaghu本と同じように、DBがどのように作られているかを知るのに良い教科書。問い合わせ最適化などに関しては、こちらの方が詳しいです。Raghu本では、データベースの知識を広く扱い、それぞれに大事な視点を紹介しているのですが、こちらの本ではその定式化、アルゴリズムの詳細にまで踏み込んでいたり、と充実しています。

次はトランザクション管理の本を紹介。データベースにおけるトランザクション管理の実装には、これでもか、というくらい非常に多くの知識を要します。まず、データベース上で多数の検索・更新処理（トランザクション）を並列に実行したときに、安全にデータを保存するとはどういうことか、そして、更新に失敗したときに、どうやってもとの状態にデータベースを復元するか。さらには、並列化しトランザクションのスループット（1秒あたりに処理できるトランザクションの数）を向上させるために重要な、ロック管理（どの部分のデータを保護し、どの部分にアクセスを許すか）についてなど。これらについて把握していなければ安全・かつ高速なDBなどはとても実装できないでしょう。

Gerhard Weikum先生による「Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery」は、トランザクション処理に関する古典的な話題から新しい話題までを理論・実践の両面から初めて整理した画期的な本です。この一冊があれば、過去のトランザクション理論の本は読まなくても良いくらい内容が充実しています。
ここで導入される階層化ロックという概念により、1993年にトランザクション処理の大御所であるJim Gray（一昨年にボートで遭難。いまだ消息不明…）が書いた「Transaction Processing: Concepts and Techniques(こちらは詳細な実装に興味がある人にお薦めです)」にあるような従来のロックの管理方式の正当性が、綺麗な形で裏付けされていくのは圧巻です。Jim Gray本人が「自分が書きたかった本」と称賛するのもうなずける内容。特に関連文献の項が充実していて、この一冊があれば、過去から現在までの研究の流れが非常によくわかり、詳しい情報へのアクセスが容易になります。

ロック理論だけではなく、実装上の問題、障害回復、分散トランザクションと、トランザクションに関する話題は網羅されています。B+-tree以外のindexがなぜトランザクション処理にはうまく使えていないのか、など、トランザクションを極めようとするなら、ぜひ手元に欲しい１冊です。

最後は、データベースの歴史を知る上でとても大切な一冊。PostgreSQLを開発したMITのStonebraker先生らによる「Readings in Database Systems」（通称 red book）です。この本は、過去30年に渡り重要な功績となった論文を集めたものです。30年の間に蓄積された論文の数は膨大で、どこから読み始めればいいかわからないものなのですが、この論文集のおかげで、重要なものから順に読んでいくことができます。論文以外の解説記事も面白く、1979年にCoddがRelational modelを提唱した前後、どのようなデータベースシステムが良いかという議論が活発になされて、結局どのような顛末になったかまで書かれてあります。XMLのような階層型データも当時から話題であったし、データの意味・モデルに基づいたsemanticデータベースや、最近よく話題になるような、プログラムで扱うオブジェクトの保存に特化したオブジェクトデータベースなども昔、一度市場から消滅している過去があるのです。

実装に特化した話も秀逸で、なぜDBMSではトランザクション管理、インデックスなどをモジュール化した実装ができないのか、分散（クラウド）データベースでは、どのようなシステム構成が考えられてきて、落ち着きどころはどこか。さらには、なぜXMLデータベースは成功しないか、など一刀両断していて、長い歴史をみてきたからこそ書ける切り口がとても面白い本です。Stonebraker先生も、5年10年も立てば、昔に熱心に議論されたことが忘れられて、また同じような研究が盛り上がるような現状を危惧してこれをまとめたとか。「歴史は繰り返す」というのは本当ですね。（はてな界隈でもこの「歴史は繰り返す」現象をよく見かけるのですが、大人げないので敢えて突っ込みを入れるようなことはしていません）

他に、これらの本がお勧めな理由としては、世界中の大学でデータベースの講義用の教科書として使われていて、Googleで検索するだけで講義資料が手に入る、というのも特徴です。さっと内容を調べたいときには、講義資料を検索するとよいでしょう。

研究寄りの話ばかりしてないで、もっと実用的なOracleとかMicrosoft SQLServer、DB2などの商用データベースや、オープンソースのPostgreSQL, MySQL, SQLiteなどを紹介したらどうしたって？そんなに欲張らなくても大丈夫。最初に紹介したRaghuの本でも読んでおけば、それぞれの製品で、SQLで検索・更新がどのように実行され、indexがどう使われるのかなんて、すぐわかるようになります。他に必要な知識は、SQLの方言や、それぞれのシステムでデータがディスク上にどのように配置されるかという情報くらい。それがわかれば、検索の種類やテーブル設計の違いで、パフォーマンスにどのような影響がでるか、より正確に把握できるようになることでしょう。オープンソースのシステムなら、このようなDBの知識を持った上でソースコードを読んでみると、素早く全体の構造から実装の詳細までを把握することができます。

東大で学んだ「勉強」の意味－「教わる」から「学ぶ」へ

2009-01-03T21:25:00.027+09:00

以下の記事を読んで、これは大学としての文化が違うのだなと感じました。

大学ってもっとすごいところだと思っていた。

なんかこう、毎日が発見に溢れていて大学じゃなきゃ知り得ないことがたくさんあって・・・
そんな素晴らしい世界だと思っていたのに・・・。

大学で秘伝を習うたった1つの方法

対価を支払っていないから秘伝を知り得ていないのだ。そこにいる人たちの中で、賢い人たちは全員秘伝を知っているし、その取得方法もわかっている。
とりあえず自分が、秘伝を教えてもらえるのにふさわしい対価を払えるようになろう。さすれば、自然と大学にある知の秘伝があなたのものになる。

どうやら大学には「秘伝」なるものがあって、それは「対価」を払って「教わる」か「引き出す」ものらしいです。「対価」として考えられるのは、学生さんのポテンシャルであったり、議論していてわくわくさせてくれるような「きらりと光る何か」だと思います。そういった教えることへのやりがいを感じれば、教員の方も喜んで「秘伝」を伝授する（とは思います。少なくとも僕自身に関しては）

しかし、いざ「秘伝」とも言うべき知見の集大成である論文や、コンピューター系ならソースコードが目の前に差し出されていても、内容を自分で読もうとしない（あるいは読み切れない）人が多く見受けられるようになりました。

近年、大学院での教育に重点が置かれるようになって、東大の大学院にも、東大の学部を経ずに、他の大学からの学生が多く入ってくるようになっています。もちろん、そこらの東大生より優秀な人もいるので驚かされることもありますが、どちらかというと、カルチャーショックを感じることの方が多いです。それは、彼らに共通して、

勉強は「教わる」ものだ

という意識が非常に強いこと。知人の助教（こちらも東大上がり）と話していても、やはりそう感じるそうです。

実は、東大に伝わる「秘伝」は、この正反対。

勉強は自ら「学ぶ」ものだ

「勉強」は人様から教えてもらうものではなく、自ら学んでいくもの。この意識が染みついてていたから、「勉強ができる＝なにがいい？ (404 Blog Not Found)」などで述べられている人から押し付けられるという「勉強」の定義の仕方には非常に違和感を覚えます。

また、東大で講義を受けていると、

「わからないところは自分で学ぶのが、大学院ですからね」

と言われることが多くあったし、大学時代の研究室の教授に、

「私は私の研究をします。みなさんも、自分で好きな研究をしてくださいね」

と、まったく教授から研究指導を受けなかったにもかかわらず、その研究室にいたメンバーのほとんどが、いまや旧帝大の教授にまでなっている、という実話もあります。

僕が卒業した東京大学理学部情報科学科なんてところは、C言語の授業がカリキュラム上に全くないにもかかわらず、C言語でプログラミングする課題が出たり、「Javaくらい自分で学んでくださいね」とか言われたり、そういうのが当たり前に要求されるので、学生の方も自分で本を買ってきて1週間で新しい言語を学んで課題を仕上げてくる、というのが日常茶飯事になっています。

それに、僕の専門はデータベースなのですが、それに関連した講義は、在学中にたったの1コマ、さわり程度の授業しかありませんでした。DBのことは本当に論文と教科書だけで学んでいます。データベースの学科があって懇切丁寧なカリキュラムがある大学がうらやましくて仕方がないです。

教えてもらわなくても人が育つのが東大というところ。ただ、先にも述べたように、学生さんの方の意識が「教えてもらう」側に傾いてきているので、最近は、教える側もより丁寧にと力を入れています。従来のように、「残りは自分で勉強してきてね」、と放り出すだけだと、「勉強」しきれずに、試験・レポートで大半がさんざんな成績になってしまったり…。それでも、どんなに難しい試験だったとしても、満点はいつもいて、自ら「学べる」人がちゃんといることがわかります。

東大生が「学歴」を気にしないというのは、それはもちろん少なくとも日本の中ではトップクラスの大学だから引け目を感じなくて済むというのもあるけれど、「自ら学ぶ力を持った人」の強さを知っている、というのも大きい。「学ぶ力」は「学歴」を問わないから。だから、先のエントリで大学に失望している人には、もっと多くを自ら学べるように「頑張れ」とエールを送りたいと思います。

（追記）

誤解のないように断っておきますが、東大の前期教養課程（1～2年時）の必修科目の講義（特に実験など）は教材・教育方法に力を入れていて非常に丁寧です。実験データの整理の仕方など、論文を書くときに必要な力を叩き込んでくれます。だから、グラフには単位までしっかり記入するなどといった基本が身についてない他大学の学生さんをみると、逆に、ちょっとがっかりするものです。。。

（さらに追記）

誤解を招きそうだったので補足。東大の授業が手抜きなわけでは決してありません。ただ要求するレベルが総じて高いものになるため、授業が「手取り足取り」というわけにはいかず、必ず自分で学ばないといけない部分が出てくるのです。プログラミングなら、オブジェクト指向の考え方などはほとんど教わりませんが、オブジェクト指向で組まれたコードを読み書きする必要はあったりします。または、最新のCPUのアーキテクチャについて書かれた論文をぽんと渡されて、それを読んで発表する授業など、習った知識だけではこなせない課題が出されることも往々にしてあります。

（補足：2009年1月18日)

こう書くと、学生が皆自ら「学ぶ」のなら、大学の存在意義はないと思われるかもしれません。けれど、それだけでは「学ぶ」ことを続けていくには十分ではありません。なぜなら、周りに何もないところで、勉強を続けていくのは至難の業でからです（教育機関が整っていない国や地域のことを想像してみてください）。「学ぶ」ための題材、施設、そして学ぶ意欲を刺激する教師や仲間が集まってくることに、大学の本当の価値があると思います。

湯島天神の初詣

2009-01-01T00:43:00.011+09:00

皆様、あけましておめでとうございます。

年末に頑張って論文を書こうとしていたのですが、かなりの熱が出て4日間ばかり寝込んでしまい、結局何もできませんでした。皆が休みの日は休め、ということでしょうか。とほほ。子供が生まれてから、土日に働くのが難しいことをつくづく実感したので、そもそも休みに仕事するような計画ではいけないのでしょう。

大晦日にようやく回復したので、毎年恒例の、東京天神うどんさんの年末限定おそばを食べに行きました。あたたまります。

湯島天神は11時頃には初詣客が押し寄せ、警官も交通整備をしていたりと、もう大混雑なのです。到着に遅れてしまったときは、年末は夜通しで営業しているこのお店でちょっとくつろぐのが一興です。

下の写真で中央奥が湯島天神で、この位置で参拝まで約45分待ち。でも、行列はもっと後方まで続いているので1時間待ちは必至。寒いので防寒用具は忘れずに。

毎年この様子を見ていて思うのですが、実は、ここ以外にも比較的、列が短く、中に入りやすい場所があるのです。写真の天神正面から並んでいる人たちは今回が初めてでそちらの入口を知らないのか、待ち行列なんて苦にしない方々なのか、あるいは伝統を重んじて「年籠り」を路上でしているのか、いつも不思議に思っています。

僕はどうするかというと、元旦を避け４～６日くらい過ぎてからようやくお参りに行っています。もうそれは初詣というべきものではないのかもしれませんが、湯島天神の菅原道真様も、人が少なくなった方がゆっくり話も聞けるでしょう、ということで。

それでは。今年もよろしくお願いいたします。

XML時代の終焉 ~ XMLから再びCoddへ

2008-12-22T10:00:00.020+09:00

先日、ACM SIGMODの日本支部大会に招いていただいて、「Relational-Style XML Query (ACM Portal http://doi.acm.org/10.1145/1376616.1376650)」について講演をしてきました。Relational-Style XML Queryは、XMLという複雑な構造をもったデータに対して、SQLのようなテーブルデータへの検索に使われる言語で問い合わせする手法です。

この研究の肝は、木構造データといわれるXMLでも、実はそのほとんどがリレーション(Microsoft Excelのようなテーブル形式のデータ）の組み合わせと考えることができ、そのテーブル構造の情報（スキーマ）を使うと、検索が非常に簡単に書けるという点です。

Relational-Style XML Query @ SIGMOD-J 2008 Dec.

View SlideShare presentation or Upload your own. (tags: xml amoeba)

この応用例は広く、僕が日常的に構造を持ったデータを扱うプログラムを書くときに欠かせないツールになっています。例えば、

XMLデータからObject へのマッピング (O-X Mapping) 。この際に、DTD, XML Schemaなどは必要ありません。Objectのクラス定義が、そのまま自動的にXMLクエリ(スライド中のrelation + FD) に対応するからです。
RDBのようなテーブルデータも木構造データのサブセットなので、検索のアルゴリズムは同一のまま、直接O-R Mappingにも使っています
他にも、コンパイラを自作したときにでてくる構文木を、オブジェクトに手軽にmappingするときにも使います。これも、O-X Mappingの一部。
JSON, YAML, CSV, Tab-separated dataなども、木構造データとしてXMLと同一に扱えます。これらのフォーマットへの対応はadapterを1つ書くだけで済んでしまいます

これらの技術は、日常的にデータベースの扱いが欠かせないバイオインフォマティクスの分野で活用しています。他にも現在研究中で、ここに紹介できるほどまとまってはいないのですが、それでも十分有用な応用というのも多数あります。今後、それらのC++/Javaなどによる実装は xerial.org （エクセリアルのサイト）を通して、追々公開してきたいと思います。僕自身、このおかげでSAX/DOMなどのプログラミングから解放されています。

XML・DB研究者の間では、XMLについて巷で言われているような「XMLがすべてを解決する」的な、XMLの利用価値についてはとても懐疑的です（ある日のTwitterでのTimelineより)。実際、XMLはXPath, XQuery, XSLT, DTD, XML Schemaなど関連技術の仕様が膨大で、学ぶのに非常に時間がかかるものでした。Relational-Style XML Queryが示す世界は、XMLをテーブル構造の組み合わせと考えることで、複雑そうに見えていたXMLが、実はとても簡単に扱えようになるというもの。

必要なのはちょっとした発想の転換です。XMLというデータありき、ではなく、最終的に扱いたいデータが、オブジェクトの形や、テーブル形式であるなら、それはもう巷で言われるようななんでも屋さんのXMLではなく、1970年代にCoddが提唱したrelational modelと同じ世界です。そこでのXMLにはportableで便利なテキストフォーマットとしての価値しかありません（データを表現するための共通テキストフォーマットが確立したという意義は非常に大きいですが）。

1997年にXMLが登場して早10年。皆こぞって、Coddが提唱したrelational modelからXMLへの転換を試みてきました。けれど、そのようにもてはやされたXMLも再びCoddに帰って行くのです。

参考：A Web Odyssey: from Codd to XML. Victor Vianu (PODS 2001)

XML、relational modelのどちらが技術的に優位か、という話ではありません。大事なのは、そのデータを扱うのは「人間」という視点です。その「人間」にとって結局、どちらが扱いやすいデータ構造なのか？僕自身は、この境目は非常に微妙なところだと考えています。Excelのように単一のテーブルだけだと心もとない、けれど構造が入り組みすぎても、扱いきれない。そして、このもどかしさと真正面に向き合うのが、データベース研究の世界なのです。

Gmailのショートカットキーが覚えられないときは

2008-12-17T19:06:00.008+09:00

「?」キー（Shift+/)を押しましょう。ショートカットキー操作の一覧が出てきます。

この中で僕がよく使うのは、

g, i と押して inboxに戻る（再読み込みにも使います）(Go to Inbox と覚えます）
g, l (Go to Label) と押して、ラベルを検索
/ で検索窓にフォーカスを合わせる
メールを見ながら、「.」を押して、ラベルを付ける　（ラベルを選ぶときに、頭文字のキーを打ち続けると早く選べます）

などです。お試しあれ。

[講演案内] Relational-Style XML Query

2008-12-15T11:19:00.006+09:00

講演の案内です。

第3回先端的データベースと Web 技術動向講演会
（ACM SIGMOD日本支部第40回支部大会）
「VLDB2008 国際会議報告および XML DBの最新動向」

2008年12月20日(土)に、「Relational-Style XML Query」の話題で、SIGMOD日本支部大会において講演を行います。申込期限は過ぎておりますが、まだ若干席が残っているようです。

Relational-Style XML Query
XMLのような階層構造を持ったデータに対して、フラットなSQLを用いて問い合わせを行う手法であるRelational-Style XML Query (SIGMOD2008で発表) について紹介します。

この内容を日本(語)で紹介するのは初めてですし、横田先生の案内によると、「どうしたらSIGMODに通るような論文を書けるか」についても期待されているご様子なので、その当たりの話も織り交ぜようかと考えています。乞うご期待。

Michael Crichtonの思い出

2008-12-04T11:37:00.008+09:00

小説家として有名なマイクル・クライトン（Michael Crichton）が、先月11月4日に咽頭がんで亡くなっていたそうです。驚きでした。映画化もされた「ジュラシック・パーク」や、NHKで放送されていた海外ドラマ「ER」シリーズの原作者と聞けば、ご存じの方が多いのではないでしょうか。

彼の著作との出会いは、NHK FMの青春アドベンチャー。「ジュラシック・パーク」、「スフィア」などの作品がラジオドラマで放送されていました。緊迫する展開、スリラーという言葉をそこで覚え、本屋で洋書を手にとり、英語が十分に読めないにも関わらず、ドキドキしながら先が楽しみで読み進めていった記憶があります。

（話はそれますが、青春アドベンチャーでは、谷山浩子さんの「悲しみの時計少女」、村山由佳さんの「おいしいコーヒーのいれ方」なども面白かった記憶があります。）

「ジュラシックパーク」以降の彼の著作はほとんど読んでいます。でも、まさか最近読んだ「Next」（バイオサイエンスを題材にした小説）が最後になるなんて。（今月、彼の最後の遺作として「Untitled Crichton」（タイトルが未定のままの小説）が、出版されるようですが）

映画ももちろん面白く作られてはいるのですが、彼に関しては原作の方が断然お勧めです。恐竜の怖さを強調した映画「Lost World（ロスト・ワールド）」 (ジュラシックパークの続編）も、原作を読んだときの深さや迫力に比べると、全然物足りないものです。

惜しい人を亡くしました。謹んで哀悼の意を表します。

Googleで論文が書けるか？

2008-12-03T13:55:00.013+09:00

Googleに入って論文が書けるか？中の人が答えています。

Official Google Research Blog: Can You Publish at Google?

A common question I get is "How hard is it to publish at Google?" I want to dispel the myth that it is hard. It is easy to publish, easy to put code into open source, easy to give talks, etc. But it is also easy for great research to become great engineering, and that is an incredible lure.　（よく受ける質問が、「Googleで論文を書くのは難しい？」というもの。実際難しくはないし、コードをオープンソースにしたり、発表したりするのも問題ない。それに、いい研究をいい製品にもしやすい。それがGoogleの魅力だ。）

察するに、論文を書くことができるか？という文字通りの意味ではYes。でも、論文を書くためのincentive（きっかけ、強い動機）が生まれるか、インパクトのある論文を書けるようになるか、という点では、ちょっとわからない。ここで解答している人も、Googleに入ってから筆頭著者（first author）で論文を書いているわけではないし、Papers written by Googlers に紹介されている論文も、僕が知っている分野に関しては、Googler(グーグルの社員）単独のものではなく、もとから論文を書ける力のある人がGoogleの中の人と共著になっていたりする。あるいは、論文を書いてからGooglerになった、という傾向。

同じようなコメントが日本のGooglerからも欲しいものです。少なくともPapers written by Googlersの日本版が。というのも、大学関係の人の間では、論文を書く力がつく前の人材（学部・修士課程を終えたばかり）が、プログラミングができるという理由で、日本のGoogleに青田買いされている現状を非常に懸念しています。「論文を書ける」人材が本当に欲しい場合、僕が人事担当なら、PhDを持った学生、あるいは自力でそこそこの論文誌・学会に採録される論文を書いた経験のある人しか採用しません。

大学のように入ってから中で鍛えるのならそれで良いですが、鍛える力を持った人、論文を書くことに強い意識を持った人が中にいないのなら絶望的です。青田買いされた人材が、論文に関しては青田のまま終わってしまいます。Google以外の会社や大学の研究室でも同じことが言えて、研究志向を持っていない（過去にあまり論文を書いていない）人が上司になるだけで、論文を書くことは相当難しくなると思います。

論文が自身のキャリアにおいて大事なら、「書ける」かどうかだけではなく、「書くために必要な要素（論文へのincentive、経験を持った師匠となるべき人）」が揃っているかどうかも、ぜひ確認しておきたいところです。

はてなブックマークレットのデザインを変更する

2008-12-01T13:15:00.010+09:00

久々にIEを使ってこのブログを開いてみると、デザインが意図していたものと全然違っていて愕然。

デザインを修正し、ついでに、はてなブックマークレット（左に表示される注目・人気エントリー欄）のリンクも、淡い色に変えました。

以下はスタイルシート（CSS)の例。

.hatena-bookmark {
padding: 0;
text-align: left;
font-size: 12px;
}
.hatena-bookmark-widget-title a img {
display: none;
}
.hatena-bookmark-widget-footer {
display: none;
}
.hatena-bookmark-count a {
margin-left: 0.5em;
text-decoration: underline;
}
.hatena-bookmark-count em a {
font-weight: bold;
display: inline;
font-style: normal;
color: #0099CC;
}
.hatena-bookmark-count  strong a {
font-weight: bold;
font-style: normal;
display: inline;
color: #FF9090;
}

ちなみに、はてなブックマークレットは、

http://b.hatena.ne.jp/entrylist/widget?url=http://leoclock.blogspot.com/

のリンクから作成でき、上のような独自のCSSを使う場合には、テーマを「なし」として使います。

SQLite JDBC 3.6.6.2 リリース

2008-12-01T10:55:00.002+09:00

SQLite JDBC 3.6.6.2をreleaseしました。

http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC

もともとのSQLite 3.6.6に混入されたバグの修正版です。

論文を書く前に知ってほしい「言葉」の大切さ

2008-11-26T11:06:00.039+09:00

「言葉」で「知性」のすべてが伝わるわけではない。そんなことは百も承知しています。

文章は知性の顕現の一種に過ぎないよ

以前のエントリ「知性が失われてはじめて言語が「亡びる」」では敢えて「知性」とは何かを定義しないで話をしています。「丁寧な文体」が「知性」と同一だとは言っておりませんので、あしからず。それゆえ、リンク先での「知性」とは何かという議論に反論する理由はなくて、実際、そのとおりだと思います。

少なくとも、僕ら研究者は「知性」を育て「知性」を見出す仕事をしています。つまりは現場の人間です。言葉がつたなくても、対話的にその人の持っている可能性などの「知性」を見出すのが大学という場であり教師の仕事なら、「知性」を持っていることを自らが外に伝えるのが論文です。論文の場合、表現やプレゼンテーションなど、「知性」を伝える力も含めて「知性」と考えます。

もちろん、中身がからっぽでいいかげんなら、きれいな文章でいくら取り繕ってもだめです。

論文を書くということは、自分の知性を他に認めてもらう行為です。but, but, butと続く論文は決して読みやすいものとは言えません。しかも、言葉を疎かにして、他人（しかも学生なら、目上の教師）に馴れ馴れしく話しておきながら、「自分は賢い」と認めてもらおうとは、非常におこがましい態度と言わざるを得ません。査読する側としては、読みにくい文章・要点を得ない下手なプレゼンテーションから「知性」を見出すことを強いられるために、意味が伝わりさえすればいいという書き方は迷惑極まりなく、「論文」という媒体でやるべきことではないと強く思います。

研究の世界の査読システムは、人の善意で成り立っています。お金がもらえるわけではないし、年間に何十本と読むものなので、自分の研究時間が削がれていくばかりなものです。それなのに、肝心の論文を書く側に、言葉を洗練し、内容わかりやすく伝えるための努力、読んでもらう人への敬意がない。そんな論文ばかりが集まってくるようだと、査読する側も疲弊し「知性」を見出す努力が続けられなくなります。結果として、重要な学問への貢献が見い出せなくなる、学会・論文誌の質が下がる、と悪循環に陥いるのです。

論文の査読の評価項目には、「プレゼンテーションの良し悪し」というものがあります。評価が高い論文はきまってプレゼンテーションが良いもので、そのような評価を得た論文が全体の中でも常に上位を占めています。技術的に秀逸でも、プレゼンテーションが悪い論文を救出するには、査読者がshephered（指導者）の役を買って出て、論文をbrush upさせる仕事をしなくてはなりません。しかし、査読者は匿名が基本です。論文を世に出すのを手伝っても、お金も名声も得られないため、拾い上げてくれるかどうかは完全に査読者の善意に依存しています。ですから、論文からプレゼンテーションを練り直せるだけの「知性」を見出せないようなら、単に論文をrejectすることになるでしょう。

僕が本当に伝えたかったのは、書き手の方こそ、良い文章・洗練された表現を書くために頑張って欲しい、ということです。特にそれが学問という、善意や熱意で成り立っている場所ならなおさらです。

この努力を怠った結果は、既に今の日本で見ることができます。頑張って書かれた論文でも、返ってくる査読結果が数行で適当に書かれたものであったりと、査読者側が最初からやる気をなくしている場合があるのです（これは日本に限らないですが…）。投稿する側も、いまや研究の世界の普遍語となった英語で書くことが大事なので、手軽に業績を増やすために、英語で書いたものを日本語に直して出してしまおう、と、日本語としての文章を練り直す努力を怠ります。当然、査読者はさらにやる気を失います。極端なことには、論文を日本語では書かないという方向にもつながっていきます。そうしているうちに、「知性」を伝えることも、また「知性」を見出す仕事へのやりがいも日本語からは失われ、英語の世界に奪われる方向に傾いてしまいました。「知性」が失われたのが先か、「言葉」への思いが失われたのが先か。

「知性」は「言葉」だけでは伝わらないかもしれない。でも、「知性」を守り得るのも「言葉」なのです。

知性が失われて初めて言語が「亡びる」

2008-11-22T21:39:00.024+09:00

これは「逃げ」でしかない。特に研究の世界においては。

むしろこれから起こるのはネイティブイングリッシュの破壊であるとか
ネイティブの英語論文より非ネイティブの英語論文の方が読みやすい場合がないか？

論文が読みやすいとしたら、それは良く練られているからだ。そもそも、わかりやすい表現が良いというのは、日本語、英語の区別がない。文章を吟味することから「逃げ」て済むなら良いが、それでは投稿してもろくに読まれないから身を滅ぼす。安易にこのような考えに同調する人がいるのがとても心配だ。

日本人が書いた日本語論文であっても読みにくい例の枚挙には暇がない。口語の方がわかりやすい？口語中心のブログでも読みにくい文章はうんざりするほどある。（例えば、「日本語が亡びるとき」の書評を批難したり、あるいは水村美苗本人を攻撃するときに、読みやすく、かつ、知性をうかがわせる文章で応えた人はほとんど見受けられない）

もし世界の標準が「日本語」で、皆が日本語で論文を書くようになったとしたらどうだろう。段落ごとに「てにをは」や「漢字」の間違いが出てくるような論文は、すぐに読む気がなくなってしまうのではないだろうか。

崩れた日本語を見たとき、まず、その言葉を操る人の知性が疑われることを肝に銘じてほしい。それが英語であろうと、ブログのような媒体であろうと同じだ。投稿される論文の中には、方言や崩れた言葉が多く混じったものもあるだろうが、競争の世界の中で消え去って日の目を見ることはない。もし表に出てくるのであれば、その論文誌・学会で査読が機能しておらず、「知性」が失われつつある兆候だ。

先の意見は「日本語が亡びるとき」を「英語が亡びるとき」に置き換えてみたのだろうが、間違った用法がはびこるから「亡びる」というのは、大きな読み違いと言わざるを得ない。

言語が「亡びる」のは、その言語を使う人の知性が失われた時だ。

（追記）

日本人特有の英語の書き方に興味があるなら、「日本人の英語 (岩波新書)」を手に取って読んでみることをお勧めする。文法ミスとまではいかなくても、意味の通じない日本人英語の例がいくつか紹介されている。The Elements of Style (Elements of Style)を読むと、英語のネィティブであろうと、「必要なことだけを書く」ために文章を練りなおさなければいけないことを教えられる。日本人の英語、論文が受け入れられないのは、日本人特有の不自然な英語が出てくることで、まず「知性」が疑われ、次に、文章で伝えるべきことをsuccinct（簡潔）に書けていないために、査読者に苦痛を与えているという事情が大きいと思われる。英語が不得手なほど、簡潔に書くための努力が必要となる。今後、多くの日本人が、「良い論文を書くために」内容ともども、文章も十分練り直して欲しいという思いを込めて。

こどもから教えてもらった「日本語が亡びるとき」

2008-11-21T10:53:00.030+09:00

一緒に塗り絵をしていたときのこと。出来上がった絵をみて、5歳のこどもが

「ぱわふるだねぇ～」

といいました。・・・可憐なディズニープリンセス（シンデレラや白雪姫、ジャスミンなど）の絵なのに、「ぱわふる」？

どうやら、いろんな色で塗っていることを指して「ぱわふる」と言っている。なるほど、「からふる (colorful) 」のことか。

正しい使い方を教えてあげて「あ、そうか～」とちょっと恥ずかしげに、納得した様子。

それからしばらくは「からふる」と言っていたのですが、先日、

「色とりどりだねぇ」

と素敵な日本語を使うようになりました。保育園の先生に教えてもらったのかな？

こどもの言語の覚え方は、まさに体当たり。恥をかいては、覚える、使ってみる。また恥をかく、の繰り返し。こどもならではの記憶力の良さも影響しているでしょうが、大人であっても、このように体当たりで英語を学習すればすぐに上達することと思います。

ただし、大事な大前提が１つ。それは、正しい使い方を教えられる人がいること。

日本の高校までの英語教育において、体当たりの英語を聞いて、正しい使い方を教えられる人がいったいどれくらいいるというのでしょう？この程度の英語力で「英語が得意」と評されるあたり、「日本語が亡びるとき」という本の伝える危機感が、うまく広まらない理由が感じ取れます。なんとか通じる英語ができればいい、という程度の話ではないのです。

「colorful」を「色とりどり」と言う。この「雅（みやび）」とでも言うべき感覚を、いったい誰が英語の世界に教えるのでしょう？日本語は、外の言葉を外来語として吸収して豊かになっていくかもしれない。実際に、過去から現在に至るまで、英語の世界に追い付かんと「翻訳」できる学識を持った人が、英語にある概念を取り込むことで、日本語は様々に変化してきました。

しかし、現代ではその取り込み方すら安易になってきています。「コンプライアンス」という言葉がそのまま使われるように、なんのひねりも工夫もないまま言葉が輸入される時代。フランスという言葉でも、敢えて「ふらんす」「仏蘭西」と書くことで、文の持つ趣、読み手に与える印象を豊かにできるというのに。人は、その感覚をまだ失ってはいないと思うかもしれないけれど、歴史を紐解いてみれば、「かふして」を「かくして」ではなく、「こうして」と画一的に現代かなづかいに改めてしまったことで、すでに失われた使い方、言葉の感覚も日本語には多くあるのです。（これらの例は「日本語が亡びるとき」より）

たとえ音が同じでも、意味が同じでも、「書き言葉」としての日本語には、読み手に「色とりどり」の快楽を与える力があります。そんな日本語を操るべき人が、英語の世界に取り込まれていく。学ぶことに意欲ある人ほど、体当たりで教えられる教師がいない日本で英語を学ぶことの困難に直面し、日本語を書くことに注ぐ時間、情熱がどんどん失われていく。

英語に日本語の言葉をアルファベットで取り込んだとしても、決して伝えきれないこの日本語のもつ豊かさ。日本語を操る人しか知りえないこの感覚は、世界の中で閉じていくばかり。そうして言葉の担い手たる人が英語の世界に吸い込まれ、日本語が次々と英語の世界の言葉を取りこんでゆくうちに、いつしか日本人すら、日本語が持つ「色とりどり」な美しさを忘れていく。

AdSenseをやってみた - 追記 -

2008-11-19T20:14:00.004+09:00

要するに「AdSenseをやってみた」で何が伝えたかったかと言いますと、

1000人の読者に対して稼ぎは5円。
例え、これが百万人になったとしても、たかが5000円
さらに稼ぐには、広告へのクリックを誘導しなくてはいけない
しかし、地道な努力を促すエントリ（たとえば、「良い論文を書くために知っておくべき５つのこと」など）に対して、「○○の秘訣を伝授」などと、甘い誘惑を囁く本末転倒ぶり
はした金を得る代わりに、文章の価値、美的感覚など、失うものが大きい。まさに「タダより高いものはない」

AdSenseをやってみた

2008-11-19T16:26:00.005+09:00

人もすなるAdSenseといふものを我もしてみむとすなり。

思ふに

1000の目で5円を恵むGoogleといふところはたいそうきまえが良く
惜しむらくは我が文の品位著しく損なわれること

人に踊らされしわが心いかがは悲しき

エジソンのお箸

2008-11-18T14:01:00.004+09:00

久々に子供の話題。

子供の箸の持ち方がなかなか直らなくて苦労しています。人差し指と親指の二本ではさむのが普通ですが、中指で上から押さえてしまうため、親指がうまく使えず、まるでじゃんけんの「グー」のような持ち方になってしまっています。

そこで思い出したのが「エジソンのお箸」。以前に保育園の先生から教えてもらっていたのですが、なかなか店頭では見かけず買いそびれていました。ふとAmazonで検索してみると、見事に発見。都心に住んでいると、こういった日常雑貨を買うのに非常に不便な思いをするのですが、さすがAmazon。便利。

先生が自分のお子さんで試して2週間くらいで直ったそうなので、うちでも購入してみることにしました。体験談はまた後日。

21歳からのハローワーク (政治家編)

2008-11-15T13:25:00.004+09:00

これから政治に参加しようと志す人ために、「13歳のハローワーク」よりもう一段深く分類してみました。

政治家

政治をする人。人気を博することでなれる。

良い政治家

教育・経済・医療など社会への貢献を評価された人。往々にして、その功績は数年、数十年という長い時間を経たあと初めて評価される。

有名な政治家

他の政治家・専門家にではなく、メディアや書籍を通じて一般の人にわかりやすく政策を伝えて評価を得る人。「国民のため」「改革」と言い続けることでもなれる。諸問題への理解度、漢字の読み書きのなどの知識は問われない。

21歳からのハローワーク（ブロガー編）

2008-11-15T13:16:00.018+09:00

これからブログを書く人のために、「13歳のハローワーク」よりもう一段深く分類してみました。

ブロガー

ブログを書く人

アルファブロガー

書いたブログで、多くの人の興味を引ける人。ただし、一度注目を集めると、内容の良し悪しに関わらずアクセスを稼ぐようにもなる。

はてな村住人

人のブログに「はてなブックマーク」を付けることを生業とし、理解不明な発言に対して、惜しみない考察、批評を繰り返せる人々のこと。

ハブ屋さん

主に他のページへのリンクを張り続けるサイトを作成し、インターネット上の交通整備を延々と行う人々のこと。語源はAuthority（たくさんリンクされるサイト）と Hub（たくさんリンクを張るサイト）から。ソーシャルブックマークサイト「はてな」もこれに含まれる。

21歳からのハローワーク (プログラマ編)

2008-11-15T13:14:00.006+09:00

これからプログラミングの仕事に就く人のために、「13歳のハローワーク」よりもう一段深く分類してみました。

プログラマ

プログラムを書く人。

ハッカー

作ったプログラムの価値を認めてもらえるプログラマ。他のプログラマに評価されるほど格が高い。

良いプログラマ

作ったプログラム、コードの品質を、仕事仲間、他の技術者に認めてもらえた人。

良い開発者 (developer)

作ったプログラムの価値を、一般の人に認めてもらえた人。使う人にとって便利なものを作れるなら、ソースコードの汚さは問われない。

ギーク

プログラム、コンピュータ関連の知識に通じている人。ただし、実際に物を作らずとも、オタクっぽい発言を続けることでもなれる。

21歳からのハローワーク (研究者編)

2008-11-15T12:01:00.024+09:00

これから研究を志す人のために、「13歳のハローワーク」よりもう一段深く分類してみました。

研究者

研究をする人。

良い研究者　　

他の研究者から評価を得ている人。

著名な研究者

他の研究者にではなく、メディアや書籍を通じて一般の人にわかりやすく伝えて評価を得る人。架け橋としての役割を担い、他の研究者からの評価は問われない。

本棚公開

2008-11-15T01:29:00.007+09:00

VOXにアカウントを作ったところ、本のリストを作成できたので、調子に乗ってどんどん追加してしまいました。

まだまだあると思うけれど、とりあえず今思い出せた洋書77冊。けっこうあるなぁ。

http://xerial.vox.com/library/books/

Leo's Chronicle

夕焼け

今週のたなくじ

Androidから

レイアウトを変更

オープンソースとフリーソフトウェアは何が違うのか

EU基準から見ても多すぎる日本の債務残高

理系のためのサバイバル英語入門

ノーベル平和賞は誰がとるべきだったのか？

東京大学理学部情報科学科のパンフレットがすごい

ぜひ押さえておきたいコンピューターサイエンスの教科書

OMakeで快適に論文執筆：TeX編

世界のトップ研究者がデータベースの未来を語る - Claremont Report on Database Research

研究者の仕事術 - 「いかに働き、いかに生きるか」

民主党マニフェストのテストコード

SSD投入でDBMSのココが変わる! - WEB+DB PRESS vol. 52

ゲノムひろば2009 in アキバ

美ら海水族館@銀座ソニービル

あなたのやる気を引きだす３つのレンズ

未来を予測する一番よい方法は、自ら未来を創ることだ

民主党マニフェストに選択的夫婦別姓が盛り込まれる？

新しいデスク

ウェブ時代に成果をあげるための心得

炭鉱のカナリア

「残念」に「残念」という禅問答

梅田望夫氏の功績

研究者はどれくらい論文を読むのか？

一人で悩んでいませんか？

データベースシステム入門：「データベースは体育会系図書館？」

NHK高校講座 世界史がすごい

もしもサーバー管理ができたなら

もしもピアノが弾けたなら

「正直」である前に「真摯」であれ ～ 草彅君の謝罪会見で感じたこと

ごめんなさいごめんなさいごめんなさい

Flash-Based DBMSの最前線

学生を成功に導くアドバイス - Ullman先生からのアドバイス

論文の先にあるもの

プログラマは世界をこう視る

子どもはどこにいるの？

SIGMOD2009 Accepted Papers

イラストで知る研究の世界とその醍醐味

PODS 2009: Accepted Papers

Pondering Bug Tracking Systems

Googleはコンピューターに損害を与える可能性があります

正規表現に見切りをつけるとき

Top 5 Database Research Topics in 2008

なぜIEはFirefoxより優れているか？

TOEIC990点より大事なこと

季節の風景 - 柏キャンパス -

ぜひ押さえておきたいデータベースの教科書

東大で学んだ「勉強」の意味－「教わる」から「学ぶ」へ

湯島天神の初詣

XML時代の終焉 ~ XMLから再びCoddへ

Gmailのショートカットキーが覚えられないときは

[講演案内] Relational-Style XML Query

Michael Crichtonの思い出

Googleで論文が書けるか？

はてなブックマークレットのデザインを変更する

SQLite JDBC 3.6.6.2 リリース

論文を書く前に知ってほしい「言葉」の大切さ

知性が失われて初めて言語が「亡びる」

こどもから教えてもらった「日本語が亡びるとき」

AdSenseをやってみた - 追記 -

AdSenseをやってみた

エジソンのお箸

21歳からのハローワーク (政治家編)

21歳からのハローワーク （ブロガー編）

21歳からのハローワーク (プログラマ編)

21歳からのハローワーク (研究者編)

本棚公開

NHK高校講座世界史がすごい

「正直」である前に「真摯」であれ～草彅君の謝罪会見で感じたこと

21歳からのハローワーク（ブロガー編）