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

先日、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のショートカットキーが覚えられないときは

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

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

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

などです。お試しあれ。

[講演案内] Relational-Style XML Query

講演の案内です。

第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の思い出

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

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

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

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

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

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

Googleで論文が書けるか？

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、経験を持った師匠となるべき人）」が揃っているかどうかも、ぜひ確認しておきたいところです。

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

久々に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 リリース

SQLite JDBC 3.6.6.2をreleaseしました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（追記）

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

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

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

「ぱわふるだねぇ～」

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

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

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

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

「色とりどりだねぇ」

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

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

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

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

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

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

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

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

AdSenseをやってみた - 追記 -

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

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

AdSenseをやってみた

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

思ふに

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

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

エジソンのお箸

久々に子供の話題。

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

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

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

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

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

政治家

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

良い政治家

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

有名な政治家

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

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

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

ブロガー

ブログを書く人

アルファブロガー

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

はてな村住人

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

ハブ屋さん

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

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

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

プログラマ

プログラムを書く人。

ハッカー

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

良いプログラマ

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

良い開発者 (developer)

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

ギーク

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

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

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

研究者

研究をする人。

良い研究者 　　

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

著名な研究者

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

本棚公開

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

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

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

これから研究をはじめる人へのアドバイス

まずは、この記事を書くきっかけとなった文章を紹介。リンク先を読んでみてください。

　

「彼氏が和文雑誌に載ってた。別れたい・・・」

研究の世界 上の文章はもちろんネタですが、研究を続けていくと本当にここに書かれたような、トップジャーナルに通ってなければ…、という世界が待っています。実際、僕自身もいつもこのような心づもりで研究しています。ただ、ひとつ気になったのは、自分自身の経験や、周りの様子を見る限り、Cell, Nature, Science (CNSと俗に言われます)などは、自分一人の実力だけで採録されるわけではありません。この人がいなかったらここまでの成果は出なかった、という貢献は確実にあるけれど、大抵は多くの人の長年の努力の積み重ねの結果acceptされています。

研究のインパクトの大きさ だから結果として、団体で金メダル！くらいには誇れますが、これを個人の功績と考えるのはあまりに決まりが悪いものです。僕が情報と生物の融合分野にいながら、情報系でかつ腕一本でできる研究も続けているのは、この決まりの悪さを避けたいという事情もあります。

でも、世の中へのインパクトから言うと、小人数でできる程度の仕事が中心の情報系トップクラスの会議（情報系はジャーナルより、会議の論文の方が主要です）と、Natureに載るのとでは雲泥の差がありますし、研究は常に後者を目指すべきものだと思います。なぜなら、情報系の小さなアイデアは、Googleのようにサービス化してはじめて世の中に大きなインパクトを与えられるもので、そのインパクトは論文を書くだけでは作り出せません。けれど、Natureなどの記事は、既に多くの研究者、テクニシャンを駆使しているという意味で、実際にサービスを作りだすのに近いものが多く、それゆえ大きなインパクトを残せるのだと考えています。

本当に目指すべきはPI グループや周りの研究者が優秀だと、それほど苦もなくCNSの論文が出ることもあるでしょう。ただ、そういうことが続くと、いざ自分がPI (Principal Investigator. 研究を率いる人・主任研究者) になるときに、途方に暮れてしまうのではないでしょうか。それでは、いくらCNSがあっても見かけ倒しでしかありません。さらに高みを目指して、自分で研究すべき対象を見定め、研究プランを立て、インパクトのある論文を仕上げるところまでできる力を持った人になってほしい。そのトレーニングとして、低予算、腕一本でできる研究に挑戦するのは悪くない選択肢だと思います。研究者にならず、ビジネスの世界に飛び込んでいったとしても、論文の代わりに、売れるもの・サービスを生み出すという違いだけで、PIとしての役割はそれほど大きく違わないでしょう。

研究テーマを探す　自分には才能がない？ そんなこと言わないで。同じ分野、研究室という狭い範囲の中で競争しなくたって、広く見渡せば、世の中にはまだわからないこと、うまく解けていない問題が溢れてます。どんな問題が、今手元にある「知識」「経験」という道具で解明できるのか、嗅覚を働かせてみましょう。どうも解けそうにないと感じたら、いったん手を休めて、問題を温めておくのも手です。数年後によいアプローチが閃くことだってあります。知見や設備が整って初めて取り組めるようになる問題だってあります。同じ問題をしつこく考え続けられるくらい愚直な人の方が、案外研究に向いていることもあります。

参考：寺田寅彦「科学者とあたま」

「科学者になるには『あたま』がよくなくてはいけない」（中略）しかし、一方でまた「科学者はあたまが悪くなくてはいけない」

世の中の偉い研究者達がこれが大事だ、と盛んに取り組んでいる問題が、５年１０年したら廃れていることなんて本当によくあります。情報系には、数学的に面白いという理由で盛んになったけれど、実際には誰も使わない、アプリケーションがないという論文の屍が多くころがっています。ですから、実際に研究成果を使うユーザーの視点から問題を見詰めると、今まで優秀な研究者達が気づいていなかった、まったく斬新な切り口を見出せることがあります。でも、本当にそれが新しいアプローチかどうかは、よく勉強していないと判断できないことです。そのために、普段から自分で教科書、論文を探してきて勉強を続ける習慣が必要です。あるいは、先進の研究者に意見を聞くのも早道だと思います。

サーベイする いったん取り組むべき問題を見つけたら、似たような問題がないか、この問題は過去にどのように考えられていたのか、を念頭に置いて、PubMed, Google Scholarなどで過去の論文を漁ります。ポイントを絞ってするサーベイ（研究調査）は、論文を一本一本丁寧に読むよりは素早く終えることができます。

  参考：サーベイに関するQ&A (住井先生）

問題と向き合う ひととおり調べ終わったら、他の論文も読みたい、まだ勉強が足りないという、邪念を排除して問題に取り組みましょう。最初は、コンピュータやインターネットから離れて、ノートと鉛筆だけで考えた方が集中できて良いと思います。今まで学校で習った知識などを総動員して研究計画、解法を練っていくうちに、あの授業は大切だった、と思うこともあるでしょう。大学の授業のありがたみがわかるのは、たいてい後で必要なことに気付いてからです。（話を少しそらすと、例えば、高校・大学受験の段階で、国数英理社の勉強が大切だと、勉強をしたくない子に説得するのはとても難しいことのように思います。）

勉強する意欲が一番高まるのは、この必要に迫られた段階です。意欲が十分高まったら、教科書や論文に戻って、今度は詳細に読み込んでみるのが良いと思います。読むだけではなく、実際に手を動かす（プログラムを書く、実験するなど）を交えるとさらに効率が良くなります。

論文を書く とにかく根気が勝負です。英語で8000 wordsのfull paperを書くには、書き慣れた研究者でも２週間をフルに使うようです。時間がかかるものだということを、覚えておいてください。でも、最初から上手にかけなくても心配しないで。上手になるまで書き直し、ロジックが飛ばないように修正していけばいいのです。それと同時に、問題と向き合いつつ、論文、あるいは研究テーマそのものを練っていくのが大事なことです。

　参考： 良い論文を書くために知っておくべき５つのこと

論文を投稿する 投稿する場所の選択は、自分が今後どのような研究者として生きていくかを選ぶに等しいです。CNSや情報系のトップ会議のように競争率が高いところでは、投稿数も多く、査読者の巡り合わせや、いい成果だったとしても研究の重要性がうまく伝わらず落とされてしまうなど、ギャンブル的な要素が多分にあります。いったん査読に入った後の待ち時間も長いので、長い間待って結局rejectということになると、特に将来が不透明で早く業績が欲しい院生・ポスドクの段階では末恐ろしいものです。ただし、acceptされれば、その喜び・達成感には計り知れないものがありますし、アカデミアの世界でポストを見つけやすくもなるでしょう。まさに、Publish or Perish （採択か死か）の世界です。

熾烈な競争を避け、手頃な発表場所を狙うのも良いですが、その場合、世の中へのインパクトは相当低いものになります。まず、研究を引用してくれる人が極端に少なくなることを覚悟してください。そのため、研究成果を実用化してくれる人を見つけるのも難しくなります。もっと深刻なのが、注目されなかった研究・論文の作成に費やした膨大な時間の意義を、自分の中でどう解決するか、ということ。学んだことを活かして、本を書く、ビジネスに還元するなど、自分の生きた足跡を残す方法は、トップジャーナルの論文を書くだけに留まりません。人生の選択ですので、ここは慎重に考えてください。自分の今のレベルはこうだから。。。と安易に通しやすい学会ばかりを選んでいると、PIになる訓練を怠りがちなり、かえって将来の道を閉ざすことにもなりかねません。

最後に 研究は学者たちだけのものではありません。サーベイでは、データや過去の知見を集めて検証する力が身に付きますし、ゴールをしっかりと見据えて問題解決に取り組む力は、大学を出て企業に勤めたり、ビジネスを起こすにしても重要な能力です。論文を書くことを通して学んだ、わかりやすく自分のアイデアを伝えるための能力は、プレゼンテーションにも活きてきます。たとえ在学中の短い間だったとしても、研究に取り組んで得た経験は、今後の人生において大きな糧になることでしょう。

ちなみにアメリカでは、Ph.D を取って出た学生の方が、教授より稼ぎが多くなる、なんてことはざらにあるようですね。一方、今の日本は研究する能力への評価が世界と比べて極端に低い社会になっていることには注意してください。深く研究した人の話をろくに聞かないで、あれこれ騒ぐというのはとても悪い兆候です。専門家不在の有識者会議が開かれるなど、まるで研究なんて必要ないという風潮がいたるところで感じられます。

この記事を読んでくれた人が今後大きく活躍し、様々な分野で今の日本を変える力になってくれることを期待しています。

英語コンプレックスなんて些細なこと

「日本語が亡びるとき―英語の世紀の中で」が話題になっていますね。まだ手に入ってなくて悲しいのですが、内容についてはわからなくても、多くの人が英語に壁、いわば英語へのコンプレックス（漠然とした不安・恐怖）を感じていることが伺えました。

たとえば、弾さんの404 Blog Not Foundより：

梅田さんが、なぜ、それも日本ではなくシリコンバレーにおいて、「弾さんは英語が出来てうらやましい」と、ふと軽く、しかし底知れぬ諦念をもって嘆息したのかが。

と、シリコンバレーで長く暮らしている梅田さんでも、この壁は残っているようだし、その英語が堪能な弾さんですら、

まず、本書は英訳されねばならない。皮肉かもしれないが、それが著者の願いを成就させる最短距離である。そのために、私も出来ることをしたい。残念ながら私の英語力は本書を訳出するにはあまりに不十分であり、それ以前に日本語、そして文学の教養が足りなさ過ぎる。

と、文学的作品を書くレベルの英語力に至らないことを認めています。御二方とも、実用上の英語には困らないほどの力を持っていることは十分伺えますが。弾さんの場合は、日本語コンプレックスと言うべきものもあるようで。あれだけの日本語の読解力があり魅力的な文章を書ける人なのに、不思議。人の悩み・コンプレックスを推し量るのは難しいということですね。

他にも、アメリカにいて仕事をしているだけでは足りないという趣旨の話も見つけることができました：

日々の生活や仕事に必要なコミュニケーションはできるようになっても、そのことと英語でのソーシャライズ、つまり親密な交友ができるということの間には無限の開きがある

いやはや。英語経験が豊富な方々の間でも、英語コンプレックスは遍在しているようです。

英語へのもどかしさは常につきまとう 　僕自身も、英語で論文を長く書いていますが、満足のいく表現に行きつかないもどかしさと向き合わざるを得ないのが実情です。表現のストックが溜まるにつれ、書く速度は目に見えて向上していきますが、そうして書いた文章がネィティブの人にとって、意味は通じたとしても、いったいどのような印象を与えるのかについては、皆目見当がつかないのです。

例えば、「日本語が亡びるとき」というタイトルにしてもそう。日本語ネイティブなら、このタイトルを同様の意味で「日本語の危機」や「日本語が亡びる」などと言い換えたとき、それぞれの持つニュアンスの違いを敏感に感じ取れるでしょう。

この違いは辞書的なものではなく、文化的な要因が大きいと感じます。たとえば、過去にその漢字・言葉がどのように使われていたのか。「亡国」「金融危機」など、言葉が使われた状況が現在の意味に反映されていきます。また、「亡びる」「亡びるとき」という違いでも、「亡びるとき」とした方がじわじわと迫りつつある未来を指している印象を与えます。でも、この日本語を感じ取る能力をどうやって学んだのかは、僕自身にもわかりません。

英語で似たような例を挙げるなら、Impossible is nothingがいいと思います。お願いだから文法がどうこうとか叫ばないで。見慣れないフレーズが出てきたときに、どう感じるのか。その感覚が持てないことに、英語コンプレックスを抱くのです。

英語において、このどうやって学んだらいいのかもわからない言葉の機微を感じ取る能力が要求されるというのは、英語で普段不自由なく仕事をしていたとしても、甚だ恐ろしいものです。それなのに日本ではまだ多くの人が、英語で論文を書いたり、英語で仕事をする、ブログを書くという経験に乏しく、この危機感を共有すらできない。これもまた、日本語が生き残る上で、恐ろしいことだとは思います。

英語コンプレックスなんて些細なこと  今後日本語がどういう立場になるかなど、さらに深い洞察は「日本語が亡びるとき」に期待するとして、多くの人が英語コンプレックスを抱いているようです。それなら英語にコンプレックスがあっても、そこで悩む必要はないでしょう。むしろこの状況を逆手にとって、日本語を扱える人として英語を使う楽しみを見出していけばいいのでは、と思います。例えば、

• 映画を見るときに、T女史の意味不明な字幕と十分戦えるようになります。
  
• 邦訳を待たずして、原著で読めます。（翻訳の質や、日本の出版社が原題を捻じ曲げてでも売るためにつけるキャッチーなタイトルに騙されることなく、本を楽しめます）
• 試合中も一球ごとにデータが更新されるMLB（メジャーリーグ）の良さを楽しめます。いまの日本のプロ野球の既得権益にしがみついた体質では、同等のサービスは期待できません。
• 学問なら、アメリカの大学院で、しかも優秀な人は、英語以外が母国語の留学生で占められていることをご存じでした？ 
• やっぱり英語がうまく使えなくても、日本語で生きていける

ここまでリスクを取らずに英語を楽しめるって、実はすごいことだと思います。

英語を使うのを当たり前にする  ただ、僕も、坐しているだけでは何の向上も見込めないので、読む、書く、聞く、話すの能力のうち、「書く」について、また、ニュアンスを多分に含んだ日常の話題に慣れるため、英語でブログを書くことにしました。普段論文を書く方が多いので、ブログは三日坊主になるとは思うけれど。。。

ちなみに「読む」に関しては、僕自身研究者として英語の論文を読む機会が多いのですが、小難しくて気楽に読めないものばかりです。楽しんで読むために、情報系としては一般向けで内容がやや軽めのCommunications of ACMや、Economist（世界情勢と経済の知識が足りない僕には読むのが大変ですが）などの雑誌を電車の中で読んでいたりします。読むスピードのギアを上げないと特集記事などは読み切れないので、だんだん速読のコツが身に付いてくると思います。ただし、記事の内容に興味がないとただの苦行になるので気をつけて。

「聞く」はひたすら聞く。聞きながら重ねて口ずさむと（シャドーイングと言うらしい）「話す」力にも良い効果があります。Economistを英サイトで購読すると全記事の音読ファイルがiPodで聞けるので重宝しています。PodCastのCNET Buzz Out Loudなどは遠慮のないスピードで話してくれるので、英語の生の日常会話の資料として貴重なのですが、会話が事あるごとにMac, PS3, Nintendo～と、単調になってくるので、飽きてしまいました。これも興味のあるものを選ぶのがいいですね。

「話す」を鍛えるために、歩くときには英語で独り言をつぶやいています。ぶつぶつつぶやいていて危ない人ですが、なりふり構ってはいられません。もはや勉強法なんてものではなく、ただひたすら言葉のストックを貯める、表現してみる、の繰り返しです。でも、それだけで大してお金も使わずにかなり英語を使えるようにはなりました。

このあたりの能力って表裏一体になっています。「書く」を鍛えると、頭の中で文を組み立てながら「話す」にも活きてきます。「読む」は表現を真似て「書く」につながる。「聞く」は「読む」ためのリズムを教えてくれるし、状況に応じた会話を「聞く」ことで「話す」ときの言葉の引き出しを増やすのが簡単になります。実際に声に出して「話して」いると、「聞く」ための脳ができてくる実感もあります。

本の到着が待ち遠しい。けれど「日本語が亡びるとき」を読んだ後でも、きっとここで挙げた部分は変わらないと思えるので、先にブログにしました。

たった一つの準備で勉強会は変わる

この記事で伝えたいことは一つ。

建設的な議論を始めるには、準備が必要だ。

本について語るなら、まず本を読む。輪講なら、自分が発表者でなくても、ざっと本に目を通してわからない点をチェックしておくこと。

たったこれだけの準備で、グループでの議論は実りあるものになります。本に書かれている以上の話ができるからです。その段階までいかなくても、わからなかった点を周りの人に確認し、本の内容をより深く理解することができます。

準備をしてないとこうはいきません。まず、なぜこの本を読んでいるかわからない参加者が出ます。さらに、本の紹介者の話がわからなくなると、その段階で思考が停止する。あるいは明後日の方向の議論が始まってしまいます。輪講や勉強会のようにその場で内容を尋ねられるならまだ救いようがありますが、ブログのように対話的(interactive)な議論が難しいメディアでは、理解を深める術がありません。本を読んでないから教えて、というのが通用するのは、その人が教えるに値する場合だけだと考えてください。（知見のある先達であったり、内容に詳しくなくて当然の他分野の研究者など）

大学での研究生活を通して輪講をする機会は幾度となくありましたが、参加者が本を読まなかったときの不毛さには目も当てられませんでした。本の知識は読んできた人だけのもので、読まなかった人には見せかけの充実感だけが残ります。発表側には、自分で本を読み解く以上のものは得られず、プレゼンという参加者へのサービスの重荷が増えるだけです。ですから、今では、受け身の参加者しか集まらなさそうなときは輪講を開いていません。

このような話をしているのは、梅田望夫氏がTwitterでした以下の発言に対するネットでの炎上の様子があまりにも幼稚であるから。

はてな取締役であるという立場を離れて言う。はてぶのコメントには、バカなものが本当に多すぎる。本を紹介しているだけのエントリーに対して、どうして対象となっている本を読まずに、批判コメントや自分の意見を書く気が起きるのだろう。そこがまったく理解不明だ

梅田氏は「ウェブ進化論」などの著書で、ネットをとりまく急速な変化と、そのまっただなかに放り込まれてしまった現代の若者にエールを送り続けています。著書への感想をブログに書いてトラックバックを送信した人には、賛否両論含めてブックマークしているし、内容にも目を通しているそうです。この行動を見ていると、自分と異なる意見も含めて、彼が建設的な議論を欲しているのが伺えます。初対面の人と対談するときも、その人のブログなどをあらかじめ読んでいくから、昔からの知り合いのように話が弾むといいます。

準備をした上で議論することがいかに面白いか。その面白さを知ってしまうと、その準備をしてこない人への興味が途端に失せてしまうのでしょう。何も難しいことを要求しているわけではありません。準備はとても簡単。

同じ土俵で議論をするためには、何よりもまず、本を読むこと

本の内容をすべて理解することを要求しているわけではないし、言葉で書かれたものの解釈は、聞く人のバックグラウンドによって変わるのが普通です。むしろ、その違いが面白く、新しい発見につながることもあるのです。違う観点からの解釈で、内容の理解を深めることあります。

今回話題になっている本は、「日本語が亡びるとき」という書籍。Amazonで注文してからまだ届いていないので、議論に参加できないのが残念ですが、英語でしか本当の意味で活躍できる道が残されていない研究者として、思うところがふんだんにあります。本を読んだあと、またブログで感想を書きたいと思います。

（追記）このあと、「日本語が亡びるとき」についてはいくつか雑多な記事を書きましたが、以下のエントリが、一番僕の伝えたいことをまとめているかと思います。

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

近況

論文・実験・講演資料作成・発表資料・ポスター作成

全部同時期に集中してしまって泣けてきます。

優秀なプログラマは空気を読んで空気を描く

面白かったので参戦。

• プログラミングテクニックのまとめ 　（基本といいつつ議論の余地が多いエントリ）
  
• 中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場 (そこに敢えて突っ込んでみた例)
  
• ちょっと囓っただけの素人が自分を過信して陥る三つの罠？ - カレーなる辛口Javaな転職日記（反論の反論に失敗してしまった例）
  
• そろそろ3つのポイントについて「弾言」しとくか（コードで何を作るかの方が重要と一刀両断）
  

まず、３つのポイントをおさらい。

1. 変数のスコープは小さく抑える
   
2. Do Not Repeat Yourself (DRYの原則) 同じコードは2度書くな
   
3. 言語を極めよ

この１と２は、まったく違うようで、とても似た問題を扱っていることにお気づきでしょうか。それは「依存関係」を減らすか増やすか。

矛盾を抱えるプログラマ　変数のスコープを短くすると、コードで必要なデータを近くにまとめて依存関係を減らすことができます。要するに、コードを

inputから、output(+副作用）を作る

というメソッドと同じparadigm(パラダイム: 枠組み）にまとめたいわけです。この形にすると、コードをメソッドの形に書き直して、再利用することが簡単になります。グローバル変数を多く使っているコードは、依存関係を即座に判断するのが難しく、メソッドに纏め上げるのが大変なので忌み嫌われています。

一方、DRYの原則に従ってメソッドやクラスとして一箇所にまとめられたロジックは、使うユーザーや使われる場所が増えるため、依存関係を増やします。使う場所が増えないなら、メソッドやクラスにまとめる理由は、コードにわかりやすい名前（alias)をつけるくらいの意味しかありません。例えば、あちこちで頻繁に使われる文字列型(string)の最初の文字のindexが0ではなく1に変更されたら、大惨事になるでしょう。

プログラマって、依存関係を減らそうと努力しているかと思えば、一方で依存関係を増やそうと一生懸命になる、とても不思議な生き物です。入力から出力を作る枠組みでしか物事を考えられない、可哀想な生き物でもあります。

変数のスコープを最小に抑えると、リソースを解放するタイミングを明確にできる利点がありますが、GC(garbage collection) を搭載した現代的な言語実装では、不要になったらメモリを即解放というわけにはいかないので、スコープが多少ずれていても、さほど深刻ではありません。

プログラマは空気を読む 学生向けにプログラミングの講義をしていたときに学んだのは、ソースコードを追う能力の乏しい段階の学生さんは、抽象化されたコードの「意味」ではなく、「動作」を追ってしまう、ということ。

例えば、SQLなどは高度に抽象化されたコードの典型例でしょう。（これを宣言型という人も多いですが、抽象化の度合いの違いにすぎません）。以下のSQL文、

SELECT * FROM t1, t2 WHERE t1.id = t2.id

を見て、「2つのテーブルt1とt2でidが同じ値の行を結合する」、と読み取れたなら、おめでとう！ もうあなたは立派に優秀なプログラマです。

例え内部で、lexer, parserからなるSQLコンパイラが動いていて、テーブルとクエリの静的型チェックをし、問い合わせスケジュールを組み立て、テーブルのデータ分布に基づいてスケジュールを最適化し、B+-treeとsequentialレコードを、ページロックを取得しながらserializabilityが保証されるようなプロトコルに従って検索して、必要ならライトウェイトロックで管理されたキャッシュにディスクページを保存しつつ、テーブルの結合にディスクを介したhash joinやexternal merge sortを実行していたとしても、そんなことは気にしてはいけません。SQLという入力から得られる結果の意味、つまり空気を読むことが大事です。

プログラミング言語は空気を描くもの どのプログラム言語を極めたらいいかって？ 空気を読みやすくて、自分の空気を描けるもの。できなければ拡張するか、作る。これが言語を極めるということでしょう。作るのは割に合わない？ 使いやすいプログラミング言語とその実装・ライブラリが出来上がるのを待つリスクが割に合うなら、のほほんと偶然の産物を待つのも一興でしょう。

(追記 10月29日)

考えることを減らせるように書く

長くなったのですが、同じラボにいた川中君がきれいにまとめてくれました。

「考えることを減らせる様に書く」

メソッド（関数）によるコードの整理や、オブジェクト指向による実装の隠蔽、プログラミング言語のなりたちなど、プログラミングのすべてはこの動機から始まります。すばらしい。

[SQLite JDBC] Javaで始めるSQLiteデータベース入門

SQLiteデータベースは、Cで書かれた軽量データベースです。「軽量」というのは2つの意味があって、全体のコード数が10万行程度という点（PostgreSQLは100万行に近づいています）と、データベースを保存するファイルが1つに納まっているのがSQLiteの特徴です。他のシステムだと、複数のデータベース用のファイルがあって管理が面倒なのですが、SQLiteのデータベースはファイル1つで、しかもOS互換フォーマットで保存されているので、簡単にOSをまたがったデータベースのコピーを作成することができます。

そもそもリレーショナルデータベース（日本語では関係データベースと訳すことが多いです）って何？という方は、初心者向けに用意した以下の講義資料を参考にしてください。

• データベースアプリケーション入門「データベースって何？」

Javaでデータベースアプリケーションを作成するには、JDBC (Java Database Connection)というAPIを使います。ただし、データベースを使うには、まずシステム側にデータベースシステムをインストールする必要があり、ここが慣れた人でもデータベースシステム（英語では、Database Management System: DBMSと言います）の設定でつまづいたり、面倒なことが多いのが難点でした。

このような問題を解決するために、SQLiteの軽量さを生かしたJava用のライブラリ（jarファイル）を作成しました。

• Xerial: SQLite JDBC Driver

このSQLite JDBC Driverでは、Mac OS X, Windows, Linux (i386, amd64)などよく使われるOSでSQLiteをインストールなしで動作させるために、それぞれのOSでコンパイルしたSQLiteのバイナリをjarファイルの中に埋め込んであります。これは、SQLiteが軽量だからなせる技です。プログラムの実行時に、自動的にjarファイルの中から、OSに応じたSQLiteのバイナリを取り出し、Java側でロードして使えるようにしています。

もし、少々特殊なOSや、CPUを使っていても安心です。SQLiteのCのコードを完全にJavaで動作するように置き換えたpure java版のSQLiteもライブラリに含めているので、上記以外のOSでもきちんと動作します（CをJavaコードに書き換えるのに少々無理があるので、動作は遅くなりますが）

JavaでSQLiteデータベースを使うには次の手順で行います：

1. sqlite-jdbc-(version).jar をここからダウンロードします。2008年10月現在の最新版は3.6.4です。（Maven central repoのミラーからもダウンロードできます。）
2. 下にあるサンプルプログラム(Sample.java)は、JDBCを通してデータベースの作成、検索をする例です。これをコンパイルします。
3. Javaを実行するときに、上記のJARファイルを以下のようにクラスパスに含めます。

   java -classpath ".:sqlite-jdbc-(VERSION).jar" Sample

4. これだけでJavaでDBMSが使えるようになります。お手軽！

Sample.java

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;


public class Sample
{
 public static void main(String[] args) throws ClassNotFoundException
 {
   // load the sqlite-JDBC driver using the current class loader
   Class.forName("org.sqlite.JDBC");
  
   Connection connection = null;
   try
   {
     // create a database connection
     connection = DriverManager.getConnection("jdbc:sqlite:sample.db");
     Statement statement = connection.createStatement();
     statement.setQueryTimeout(30);  // set timeout to 30 sec.
    
     statement.executeUpdate("drop table if exists person");
     statement.executeUpdate("create table person (id integer, name string)");
     statement.executeUpdate("insert into person values(1, 'leo')");
     statement.executeUpdate("insert into person values(2, 'yui')");
     ResultSet rs = statement.executeQuery("select * from person");
     while(rs.next())
     {
       // read the result set
       System.out.println("name = " + rs.getString("name"));
       System.out.println("id = " + rs.getInt("id"));
     }
   }
   catch(SQLException e)
   {
     // if the error message is "out of memory",
     // it probably means no database file is found
     System.err.println(e.getMessage());
   }
   finally
   {
     try
     {
       if(connection != null)
         connection.close();
     }
     catch(SQLException e)
     {
       // connection close failed.
       System.err.println(e);
     }
   }
 }
}

やや高度な内容ですが、MavenをJavaの開発に使っている人は、mavenのcentral repositoryにsyncされているこのSQLite JDBCライブラリを使うことができます。pom.xmlファイルに以下のような記述をするだけで自動的にダウンロードされます。

<dependencies>
<dependency>
 <groupid>org.xerial</groupid>
 <artifactid>sqlite-jdbc</artifactid>
 <version>3.6.4</version>
</dependency>
</dependencies>

SQLiteではファイルにデータベースを保存せずにメモリーの上でデータベースを構築することもできるので、データベースのテスト用にも最適です。

僕のパソコンで動いたよ！証明書

開発者にとって、作ったプログラムがちゃんと動くことを証明するのは、悩みの種。なぜなら、人によってOSの設定も、インストールされているソフトウェアも違うから、作ったコードはそのままじゃ動かないかもしれない。でも安心して！ そんな時はこのバッジを張ればいいんだ。

Works on My Machine Certificate 

僕のパソコンで動いたよ！証明書

Technical Certification Requirement
このバッジ（証明書）を発行するための技術的な要件は以下の通り：

• コードをコンパイルします（他の開発者が修正した最新版のコードを使うかどうかはあなた次第であり、この証明書の要件ではありません）
• コンパイルしたアプリケーション/ウェブサイトを立ち上げます
• 変更箇所に該当するコードを実行します（推奨する方法は、自分の手でad-hocにコードの動作を確認すること。もし変更箇所が5行に満たない場合や、開発のプロフェッショナルとしてエラーが起こりようもないと判断できるときは、このステップを省略してもよいでしょう）
• 修正したコードをヴァージョン管理システムにチェックインします

Notification Requirement

この証明書を使用するときの通知義務:

• テスターや顧客に、この証明書を開示する義務はありませんが、きっと人に見せたいと思うはずです。そして、あなた自身はきっとこの証明書を相当誇りに思うでしょうが、「僕のパソコンで動いたよ！」証明書を使うときには、むやみやたらに大喜びするのではなく、さりげなくこれは自己満足なんだよ、という雰囲気を醸し出すと良いでしょう。

使用例：

Guide to Freeing up Disk Space under Windows Vista

New Application Certification Program - "It Works on My Machine"
The "Works on My Machine" Certification Program

Works with Windows Vista Logo

Bloggerにはてなブックマークボタンを追加する

Bloggerの記事に、はてなブックマーク、delicious、livedoorクリップ、Buzzurlなどへのリンクボタンを追加する方法。

テンプレートの編集画面から、

<div class="post-header-line-1">

の箇所を探し、以下のコードを挿入します。

<div class='post-header-line-1'>
<b:if cond='data:post.url'>
<a expr:href='&quot;http://b.hatena.ne.jp/entry/&quot; + data:post.url'><img alt='このエントリーを含むはてなブックマーク' height='12' src='http://d.hatena.ne.jp/images/b_entry.gif' style='border: none;' title='このエントリーを含むはてなブックマーク' width='16'/></a>

<a expr:href='&quot;http://del.icio.us/post?url=&quot; + data:post.url + &quot;&amp;title=&quot; + data:post.title'><img alt='Add to Delicious Bookmark' height='10' src='http://static.delicious.com/img/delicious.small.gif' style='border:none;' width='10'/></a>

<a class='ldclip-redirect' expr:href='&quot;http://clip.livedoor.com/redirect?link=&quot; + data:post.url + &quot;&amp;title=&quot; + data:post.title + &quot;&amp;ie=euc&quot;' title='この記事をクリップ！'><img alt='この記事をクリップ！' height='16' src='http://parts.blog.livedoor.jp/img/cmn/clip_16_16_b.gif' style='border: none;' width='16'/></a>

<a expr:href='&quot;http://buzzurl.jp/entry/&quot; + data:post.url'><img src='http://buzzurl.jp/static/image/api/icon/add_icon_mini_08.gif' style='border:none;' title='Bookmark to Buzzurl'/></a>
</b:if>
</div>

優秀なウェブ開発者の見極め方

「Webアプリケーション技術者の見極め方（Java）」 こんな記事を見かけましたが、使えるツールやフレームワークの種類云々を聞くより、単刀直入に欲しい人材を見抜く質問はこれ。

「JavaでWebアプリケーションを開発する利害得失を述べよ」

もちろん、「Java」の部分をRubyなり、PHP、Perlなどに置き換えても良いです。僕なりの解答はまた後日。

（関連リンク）

• 面接の質問
• C++技術者の見極め方
• Webアプリケーション技術者の見極め方
• Life is beautiful: 優秀なエンジニアは「入社時のスキルを問わない会社」には就職してはいけない
• 404 Blog Not Found:イメージを形にできない人は減衰する
• FPN-プログラマーにコミュニケーション能力が必要か
• PHPやJavaのJSPやRubyのeRBのクールじゃないところ

Macのキーリピートを加速

[Mac] キーリピートを速くする方法の記事で、システムで設定できる限界値を突破する方法を書いていたのですが、効果がいまひとつ実感できないものでした。

今日発見したのが、KeyRemap4MacBookというソフトウェア。MacMiniでも使えました。インストールして、再起動後、System Preferences(環境設定）- KeyRemap4MacBookのアイコンから、キーリピート値を変更できます。

画面は、key repeatの開始までを150ms (default: 500ms)、repeat間隔を15ms（default: 30ms)に設定してみた例。おお～、速い速い。これでMacでも快適にコーディングできそうです。

どうやってこんなことを実現しているのか気になって、ソースコードを眺めたところ、kernelプログラミングで、キーボードのフィルタドライバのようなものを作っているのでしょうか、自前でキーリピートの動作を実装しています。いい仕事ですね。

[参考]Mac OS Xのカーネル拡張の作り方

このソフトは、キーボードレイアウトを変えるのが本来の用途だと思いますが、キーリピートの設定ができるだけでも十分。感謝。

学校でしか教えてくれないプログラミング言語のこと

Scheme（スキーム）というプログラミング言語について初めて知ったのは、大学2年生のときです。理学部情報科学科に進学し（東大には進学振り分け（通称：進振り）という制度があって、大学2年生の前半までは一般教養を学び、それ以降から専門課程に進みます）萩谷先生担当のプログラミング演習がSchemeとの出会いでした。（当時のものとは大分違いますが、参考までにSchemeの講義資料へのリンクです。http://www-ui.is.s.u-tokyo.ac.jp/~hara2001/scheme/)

おそらく、ここで学ばなかったらSchemeのように一般に知られていない言語には触れることもなかっただろうし、Emacs Lispのプログラム（Schemeと同様の構文です）を自分で書くこともなかったように思います。Emacsというテキストエディタは、自分好みの機能をLispを用いて実装することが醍醐味です。今でも、簡単な計算はLispで書いて、Emacsを電卓代わりにしています。（以下は、階乗の計算をちょこっとLispで書いてみた例。xのn乗を再帰で計算する関数pow(x, n)）：

括弧が多くて「何だこれは？」と思われそうですが、括弧の対応付けはエディタが視覚的にサポートしてくれるので、式そのものの見た目ほど入力は大変ではありません。

実用性という意味では、Schemeは非常にマイナーな言語だと思います。けれど、再帰であったり、リスト構造であったり、環境（変数などの状態を運ぶもの。継続とかもそう）であったり、λ関数（クロージャと言ったほうが良いかな？）など、プログラミングで重要な概念を学ぶのには良い言語だと思います。型を学ぶにはOCamlなどML系の言語の方が適しているので、そちらを授業に使う大学も多いようです。

Schemeに関しては思い入れが深く、僕にとってはEmacs（Windows版はMeadow）を使い始めたきっかけでもあるし、情報科学科のCPU実験で、Scheme言語を使って、Scheme言語のコンパイラ(自分達で作るCPU用のアセンブリを生成します）を作ってしまうくらい深く関わった言語でもあります。言語の仕様書（当時はR5RS）もそれなりに読みました。

それを最後に、久しくSchemeから離れていたのですが、思い出させてくれたのが以下の公開質問：

「プログラミングに詳しい人に質問です。大学でプログラミング経験の学部一年生向けにプログラミングを教えることを想定しています。週１コマ×半年程度の限られた時間で、プログラミングとはどういうものかという本質を教えたいのですが、どの言語を使うのが適切でしょうか。」

ここでは、プログラミング言語の種類をあまり知らない人を解答対象からはじくために、以下のような質問肢が用意されています。一般の人よりは僕はSchemeを知っていると踏んで、これを読んだときの僕の思考過程（赤文字）も併記しました。

* Schemeは1.5からオートボクシングの機能をサポートした
auto-boxingってJava…
* Schemeはインデントによってブロックを表現する
そんなわけない。括弧だよ
* Schemeは多くのレンタルサーバに標準でインストールされている
もしそうだったら凄い！
* Schemeでは関数がファーストクラスのオブジェクトである
Schemeで言うオブジェクトって何？単にデータという意味だとすると'A (文字を表すsymbol)とかあるし…。(cons 1 2)だと、関数が１と２のペア表すデータ型（オブジェクト）と捕らえることができるけど。。。
* Schemeの文の終わりはセミコロンである
違う違う。
* Schemeは純粋関数型言語であり、副作用はモナドでくるむ必要がある
副作用がない関数型言語って、関数の外側の変数を変更できないってことだよね。そんなことはなかったような、、そもそも、モナドって何？と焦りグーグル検索。。これHaskellに出てくるのか。。
* Schemeは型に厳格なため整数の加算と浮動小数点数の加算の演算子が異なる
そういえばSchemeで型を意識したことがない。。。
* Schemeは関数の呼び出し時に括弧を省略することが出来る
そんなsyntaxあったかなぁ。。。たぶんない。
* Schemeのマクロ定義には#defineを使う
C/C++だよ、それ。(define f (x) ...)はあるけど。
* Schemeの言語仕様はキューマシンとしての実装に適しているため並列化が容易である
キューマシン -> 並列化が容易というロジックにとっても飛躍を感じるなぁ。副作用無しの純粋関数型の範囲なら、Googleのmap-reduceの概念のベースになっているように簡単に分散できるけど。。。
* Schemeのブロックはbeginで始まりend.で終わる
これは違う。
* SchemeのコンパイラとしてはGHCが有名である
GHCって何?聞いたことない。Googleで検索…またHaskellですか。。。知らないよ（涙）

と、まぁ、大変でした。なぜって外部情報で補完しないと正解が出せない質問がたくさんあるから！「多くのレンタルサーバーに」って。。。「多くのレンタルサーバー」の現状を知らないとわからないし。本格的なSchemeの使用例が見当たらないって理由で推測はできるけれど。他にもSchemeにはまだ僕の知らない構文があるのかも…とか不安に思ったり。それでも、Googleで検索すればそれぞれ1分と経たずにわかる程度のことだと思います。とても懐かしく、かつ、知らないことも多くあったので知的な刺激になりました。

プログラミング教育用としての関数型言語

こと、教育のためのプログラミング言語の選択に関しては、ネットワークに接続したり、データベースを使ったプログラミングが必要なら、現時点では迷いなくJavaを選択します。動作させやすいこと、使っている人が多いためEclipseのような使いやすい開発環境が整っていることが選択の理由になります。

Scheme, Lispのような関数型言語の肝は、副作用がないという点だと思っているのですが。たとえば、Googleが超並列計算に使用しているMapReduceのフレームワークでは、

map(入力を2倍にする関数f, {1, 2, 3, 4, 5}) => {f(1), f(2), f(3), f(4), f(5)} = {2, 4, 6, 8, 10}

reduce(入力を足し合わせる関数h, {2, 4, 6, 8, 10}) => 30

というmap, reduceという２つの手続きで計算を行います。map部分をScheme(Lisp)的に書くと、

上のようになります。map関数では、入力リストの先頭(car)から順に関数fを適用していきます。たとえば、以下のような式

の結果は、{2, 4, 6, 8, 10} になります。関数の引数に関数f（lambda文を使ってxを2倍する関数を定義している）を渡して、内部では{(* 1 2), (* 2 2), (* 3 2), ... }を計算しています（+演算は前置記法）。ここで大切なのが、map関数内で、関数fの実行順に制約がないということです。つまり、個々の関数fの実行では副作用がない（！）ので、どの順番で実行してもよく、この部分を言語の実装次第で並列化することができます。

GoogleのMapReduceではこのような副作用がないというプログラムの意味(semantics)を活用して、個々のmap操作を別々のノードに計算させて超並列化を可能にしています。関数型言語を用いるとこの副作用のない部分を明確に記述できますし、驚くほど多くの計算がmap-reduceの組で書けるようです。例えば、forループで先頭から順に辿らなくても良い場合が見つけやすいと思います。Googleは並列化を促進するために、入力listのコピーをいつくかのノードに分散して配置する工夫も行っています。検索エンジン用の索引構築なども、このMapReduceのフレームワークで再実装したとMapReduceの論文には書かれています。

再帰の概念は他言語でもよく見かけますが、関数型言語の特徴である副作用がない（データすら関数で表現されている）コードの書き方というのは、手続き型言語であるJava, C/C++など、実際の開発現場でよく使われるプログラムの書き方から入った人には、とても気付きにくいものだと思います。関数に関数を渡すという概念も、何十年も前の関数型言語の研究から、他に移殖されたものです。

これらの通常では気付きにくい概念や、既に一般に当たり前のように使われていることの裏にある理論を教えるのが大学のあるべき姿であると考えます。特に、簡潔な記述で速く動くことに主眼に置くcomputer scienceの分野では、プログラミングの授業も、言語を問わず、一般の技術者向けの勉強本では深く触れられていないような、本質の部分をカバーすべきでしょう。そうすることで、近い将来、新しいプログラミング言語が出てきても、プログラミングの歴史と比較して、新しい部分、重要な技術などをはっきりと認識できるようになり、言語を使いこなす能力をもったプログラマを育てることにつながるのではないでしょうか。

（追記）

そもそもプログラミングの本質って？

プログラミングの本質をどこに据えるかで言語の選択は変わりますね。省メモリ・並列化が主眼なら副作用、同期などが重要なのでアセンブリ、C/C++などlow levelに近いもの。オブジェクト指向ならJavaなどデザインパターンの威力が見せられる言語が良いと思う。簡潔さ、手軽さが大切ならPerl, Rubyとか。関数型という意味では、Scheme, Lispも面白いけれど、Ocamlも良さそう。Python, Haskellとかは詳しくないので…。

教育で大切なこと

実際、講義の中や在学中に本質を理解しきる必要はないと思うのです。僕自身、関数型言語とMapReduceの関係なんて、卒業した後に初めて理解したものです。気付く人もいれば、数学と同じでまったく使わない人もいる。ただ後になってもう一度学習しようと思ったときに、入り口の部分を見せてもらっているのとそうでないのとでは、学習効率（学ぶことへの抵抗感）が相当違います。だから、1から10までを教えるのではなくて、1を見せることが「教育」で本当に大切な事だと感じています。

Google Street Viewが持ちえない情報

Google Street View(ストリートビュー）が、写してはいけないものまで公開していることが多くのサイトで話題になっています。今日、「不適切画像の削除作業は小鳥並の知能で行われる」：高木浩光＠自宅の日記のエントリをみて、根本的な問題がようやく整理できました。

Google Street Viewが検索エンジンのロボットやウェブ上のブログなどと根本的に違うのは、「人のフィルターを通さない情報をネットに晒している」ことに尽きます。

もちろんGoogle Street Viewのデータを収集するには、路上の写真を撮影する実際の作業員がいて、撮るべき場所の最低限の判断はしているのでしょう。（私道に入り込んでいたり、とそれすらも怪しいですが）。写ってしまった人の顔をぼかすなどの処理もしているようです。けれど、ネットに公開すべき情報とそうでない情報の判断を、98%の精度でスパムメールを弾くのと同じ方法で行ってはいけない事例が多々存在します。

例えば、写ってはいけない人が、その場所に写っていた場合。この写真をウェブに公開してもよいかという判断は、写っている場所以外の外部情報を使わないと通常はできません。なぜなら、顔が伏せられていたとしても、背格好、服装や行動範囲などでその人を特定できる情報を持っている人にとっては、ただの写真以上の情報がそこにあります。たとえ洗濯物が映ってしまったという程度のことでも、女性の一人暮らしであることがわかってしまうなど、写された住居に住む人の危険を招くことさえありえます。

「問題のある画像だから、画像を消す」という現在のGoogleの対応では、「消したという事実」によって、消された場所に何があったのか、という好奇心を刺激し、削除依頼主の意にそぐわない事態を招くことが十分考えられます。

インターネットの普及に伴い、ネットの存在意義もプライバシーの問題も議論されてきました。ネットの検索エンジンがけしからん、といういう人が減ってきたのは、利便性の認知とともに「Webに個人情報などを公開しない」という選択肢と、そのための情報の管理方法が存在しうるからです。つまり「人によるフィルター」を介在させる余地がWebに情報を送る前に残されているのです。けれど、ストリートビューにはそれがない。

目に見える情報がすべてではないのです。株のインサイダー取引のように、内部情報を知りうるものだけに利益を与え、他の人の利益を不正に大きく損ねてしまう。

ストリートビューは、今までなかなか見られなかった情報を収集し、目的地や町の雰囲気を容易に知ることができるようなったという点で、その存在意義や利便性は高く評価しています。ただ、それを人や機械の目による判定や、報告だけで安全にできるというGoogleの現在の主張には、非常におこがましいものを感じます。当事者にしかわからない情報というのは常に存在するものです。

今までのウェブ情報の収集とは違って、ストリートビューでは「人によるフィルター」の情報が根本的に抜け落ちています。「ウェブに存在しない・載せていない」という事実だって立派な情報です。フィルターを通したあとの情報を扱ってきたから、Googleには何をしても怖くないという強みがありました。ストリートビューのように、フィルターを通す前のレイヤー（層）の情報を扱いだしてから、急に対応の陳腐さが目立つようになってきたのがとても残念です。

Google Web Toolkitを本格的に使う

昨日、Google Web Toolkit (GWT)に触れたので、備忘録という意味も含めて、もう少し詳細を書いてみます。僕自身、GWTを使って、ゲノムブラウザを作ってみたり、講義のレポート提出用サイトを作成するなど、ここ数年大活躍しているツールで、GWTによるWebインターフェースで、5万行は優に超えるだけのコードを書いています。

Google Web Toolkitは、JavaからJavaScriptに変換するコンパイラと、ブラウザで表示するHTMLを生成するWidgetクラスを含んでいます。Javaの構文でプログラムを記述すれば、Webブラウザで動くJavaScritpコードを作成してくれるというものです。

実際の開発ではHTMLを書くことはなく、FlexTable, Buttonなど、HTMLでよく使うtableやformタグをクラスとして表現してくれているので、再利用可能な形でHTML要素を設計しやすくなっています。GUIインターフェースのプログラミングと似た感覚でウェブアプリケーションの開発ができる、と考えるとよいかもしれません。Perl、PHP、Ruby on RailsなどHTMLのテンプレート中心の開発と趣が異なるので、テンプレートに慣れた人にとっては最初のうちはコードを組みにくいかもしれませんが、HTML生成のまどろっこしい部分を気にせず開発できることに真価があります。

コンパイル後の最終的なコードはJavaScriptになるのですが、GWTではJavaの標準的なライブラリをエミュレーションすることで、JavaのArrayList, HashMapなどよく使うデータ構造を使えるようにしてくれています。GWT1.5からは、JavaのGenericsの構文や、forループの簡略記法を使えるようになったので、ますます開発が簡単になりました。

3種類のJAR   GWTにおける開発では、3種類のJARファイルを使います。

• gwt-user.jar  GWTでは、client（ブラウザ上で実行されるコード）と、sever(サーバー上で実行されるservletなどのコード）の2種類のフォルダ（Javaのパッケージ）を使って開発します。サーバーとの通信に必要なservlet周りのパッケージ(javax.servlet)がgwt-user.jarに同梱されていて、自分でTomcatをインストールしてこれらのライブラリをclasspathに設定する手間が省けます。gwt-user.jarは開発時のみに使うものです。
• gwt-servlet.jar  一方、こちらは、TomcatなどのWebサーバーに作成したWebアプリケーションを設置するときに、WEB-INF/libフォルダに含めておくものです。gwt-user.jarから、javax.servletのパッケージを取り除いたものです（javax.servletはTomcatに標準装備されているパッケージです）。deploy時には、gwt-servlet.jarのみを使います。
• gwt-dev-windows.jar, gwt-dev-mac.jar, gwt-dev-linux.jar  これらのJARファイルには、GWTのコンパイラが含まれており、JavaコードをJavascriptに変換するときに使います。また、GWTのコードをコンパイルせずにJavaコードのまま実行するための、GWT Shellが含まれています。GWT ShellはTomcatサーバーをローカルに立ち上げるGUIプログラムなので、OS毎に必要なJARファイルが異なり、gwtの配布パッケージに含まれている.dll、.jnilib、.soなどが実行するのに必要になります。デバッグ時には、クラスパスの先頭にgwt-dev-*.jarを追加しておきます。（gwt-user.jarなどはJavaScriptコードを含んでいるので、Javaとしては動作しません）

GWTのアプリケーションをデバッグしたり、コンパイルするには、ソースコードのフォルダ(srcとか、src/main/javaなど）と、Javaのソースコードクラスが含まれているフォルダ(binとか、target/classesなど）がクラスパスに含まれている必要があります。これはJavaのソースコードそのものがコンパイルなどに必要なためです。

GWTのためのJAR作成 したがって、GWTのコードをJARのライブラリにして再利用するときも、ソースコード（*.java)もclassファイルと同じ位置に含めて作成する必要があります。普段から、ソースコード同梱のJARを作っておくと、EclipseでJARのソースコードがすぐ参照できるというメリットもあります。

GWTによる開発を即座に始める  こう並べてGWT開発の注意事項を並べて書くと、はまりどころが多くて、設定もとても面倒なのですが、僕はこれらの設定を含めて、GWTによる開発を数秒で始めることができるようにしています。

現在開発中の、UTGB Shellというゲノムブラウザを作るためのツールでは、utgb create, utgb gwtのコマンド2つで、GWT、データベース、サーブレット機能を含めたプロジェクトの雛形を作成します。埋め込み型Tomcatサーバーを立ち上げることで、Tomcatなどのインストールなしに、ローカルマシン上でJavaによるWebアプリケーション開発ができるようにもなっています。現在は、生物系の研究者が、面倒なしにゲノムブラウザを作れるようにする趣旨のツールなのですが、僕自身、ゲノム関係以外の一般のWebアプリケーション開発にも使っています。

UTGB Shellの舞台裏ではMaven（パッケージ管理ツール）が動いています。そのインストール作業を省くために、Maven自身もUTGB Shellに埋め込まれています。また、gwt-dev-*.jarのライブラリも、本家で配布されているものとは違って、dllなどのライブラリも同梱させています。これによって、OSごとに１つのJARファイルをダウンロードするだけで済むのですが、これらのライブラリをOSの種類に応じてダウンロードしたり、展開したり、GWTのコンパイラを起動するなどもすべてMavenのスクリプトとしてまとめているので、ユーザー、開発者が、詳細を気にする必要がありません。本番用サーバー上のTomcatへのdeployもコマンド一つでできるようになっています。

このような複雑なプロジェクト管理ができるようになったのも、Javaの魅力の１つ。C++などバイナリのOS・コンパイラ間の互換性が乏しい言語の場合は、ソースコードの最新版をネットからダウンロードして、dllをコンパイルする必要があります。コンパイルエラーがでる、実行時にリンクエラー、multi-threadライブラリのタイプが一致していなくてメモリリークが起こるなど、など、慣れていない人には解決しようのない、はまりどころもたくさんでてきます。

Javaではこのような面倒が軽減され、Mavenのようなパッケージ管理ツールのおかげで、典型的な作業を繰り返さずにすむようにできるようになったのが嬉しいですね。

Google Web Toolkitでcanvasを使って画像を描く方法

Google Web Toolkit(GWT)は、Java言語からJavaScriptのコードを生成するものです。ブラウザ間のJavaScriptの動作の違いを吸収してくれるなど、ウェブアプリケーション開発の苦労をかなり軽減してくれます。GWTはもう十分実用的なのですが、まだまだ成長途中でgwt本体のtrunkに正式に組み込まれる前の機能などは、Google Web Toolkit Incubatorというプロジェクトで開発されています。

gwt-incubatorの中で目玉なのが、GWTCanvasというライブラリ。これは、次期HTML5には標準搭載されるはずのcanvasタグの機能を使って、ブラウザ自身に画像を描画させるというものです。こちらのデモを見てもらえれば、意外と複雑な図が描けたり、アニメーションが作れるなど、そのすごさがよくわかると思います。Flashプラグインなどを使わない限り、今まで画像をブラウザで見せるにはサーバーから画像データを直接送る以外に方法がありませんでしたが、今後は描画のために必要な座標、色などの情報をサーバーが送るだけで、画像を描くなどサーバーにとって重い処理はブラウザ側に任せてしまえるようになります。

実はこのcanvasという機能、IEはサポートしていません。けれど、IEにはVMLという独自の画像を描くための仕様があります。GWTCanvasは、IEのときはVMLを使って画像を描き、canvas機能が既に使えるFirefox, Google Chrome, Safari, OperaなどのWeb標準を大事にするブラウザでは、canvasを直接使う、というトリックを使って、ほとんどのブラウザで画像を描くことを可能にしています。ただし、IEのVMLを使った描画は動作が重いのでご注意。

厳しく言えば、IEがWeb標準を追おうとしてないから、こんなライブラリが必要になっている節があります。どのOS・ブラウザでも動くことを大事にするWeb Developerにとって、IEは本当に憎らしい存在。Webアプリケーションを作る動機って「どこでも動くアプリケーション」を作ることに尽きますから。IEのためだけに必要なwork aroundのなんと多いことか。

ソースコードからjarファイルを作るにはこちらを参照して、ant distとすればいいですが、僕がJARパッケージにしたものもこちらからダウンロードできます（GWT1.5.2用です）canvasで遺伝子構造を描いてみたりしています。ブラウザで画像を描き始めるとGoogle ChromeのJavaScriptの動作が本当に速いことがよく実感できます。

Googleの新しいブラウザChrome レビュー

Googleが開発しているブラウザGoogle ChromeのBeta版がリリースされました。最初から、AJAXを使ったものを含むいろいろなサイトが問題なく動くのはさすが、というところ。（Google にはChrome Botというのがいて、何百万というWebページを自動でテストしてるらしいです。）

Googleにとって、ブラウザ技術というのはサービスを提供するための基盤技術という意味で、まさにOSです。ブラウザの開発は過去にNetscapeが過去のコードを捨てて一から書き直すなどの苦労をしていたように、とても大変な領域なのですが、基盤技術を自分達で作るという正攻法に素直に取り組んで実現までしてしまうのがGoogleらしいですね。

使い始めて驚き。まず、検索バーがありません。Google Chromeのおかげで、検索バーは、本来必要ないものだったことがわかります。使い方は簡単。まず、Ctrl+Lを押してアドレスバーに飛びます。ここで、覚えているURLの一部分なり、キーワードを入れると、過去の閲覧履歴やら、Google Suggestやら、ブックマークやらを検索して、見つけてきてくれます。検索バーなどが統合された分、全体として余計なボタンが省かれたすっきりしたブラウザになっています。

新しいタブを開く操作は、IE7, Firefoxと同じCtrl+Tです。すると、普段よく見てい

るサイトがスクリーンショットとともに一覧表示されます。これは便利。反対に閉じるときはCtrl+Wと、タブを切り替えるときは、Ctrl+Tabを使います。

マウスで選択してもよいし、タブを開くとすぐアドレスバーにフォーカスが移るので、そのままキーボードで検索を開始できます。このあたりのつながりの良さが快適。

各タブ毎にプロセスを生成しているので、重いサイトがあっても、他のページは不自由なく見続けられるなど、技術的にもOS好き、プログラマにとっては興味深いことばかり。ブラウザ中にデータベースを保持できるGoogle Gearsも最初から組み込まれているのもうれしいところ。技術者には、ここにあるGoogle Chrome紹介のコミックがお勧め。（JavaScriptのGarbage Collectionを作り直しているとか、すごい正攻法。これもGmailなど, 自前のGoogle Web Toolkitで作成されている部分の高速化につながるので、自分の財産の価値をさらに高めています）

Web Developer向けの機能として、HTMLソース中の各タグの構造やスタイルを表示してくれるinspector機能がうれしい。FirefoxでFireBugsプラグインと同じような機能が最初から使えるのです。ありがとう、Google。Web開発者の気持ちをよく理解してくれています。

タブをブラウザの外側にドラッグすると、独立したウィンドウになるので、他のページを参照しながら、ブログを書くということも、簡単。

ページ表示の履歴を残さないシークレットモードもあります。のアイコンには笑ってしまいました。スパイ活動に使うのか、なるほどw。リンクを開くときに右クリックで「シークレットモード」を選べます。

IMEのon/off関係なしに、スペースキーで画面のスクロールができるし、わりと細かいところもしっかり実装されていて感心。デフォルトのブラウザに設定して、しばらく使ってみることにします。

（追記）

その他のショートカットキー

• Ctrl+F ページ内単語検索 これもシームレスで速い！
• Ctrl+U ページのソースコード表示
• Ctrl+H 閲覧履歴のページ表示
• Ctrl+N 新しいwindowを開く
• Ctrl+R ページの再読み込み
• Ctrl+J ダウンロード履歴の表示
• アドレスバーでの検索結果をAlt+Enterで新しいタブで開く
• backspaceで一つ前のページ、Shift+backspaceで一つ先のページ
• 意外と便利なCtrl+Shift+Tで閉じたタブを復元。フォームの入力内容も復元されます。何回か押すと、1つ前、2つ前に閉じたタブを復元していきます。

Shift+ESCキーで、各ページがどれくらいメモリとCPUを使っているかもわかります。すごい。

about:network でネットワークのアクセス状況、about:memoryでメモリの使用状況の詳細も見られます。AJAXアプリケーションなどバックグラウンドで通信を行う様子を確認できて便利。

雑感 GoogleがGearsを統合したブラウザを開発し、僕が２年くらい前に予測していた「ブラウザがデータベースを持つ日」がようやく実現されましたが、使う側にとっても、開発者側にとっても、データを扱うという点については、まだまだ不自由が多いと思います。例えば、Twitterの過去ログを追う、などの問題。Twitter APIからログを取得して保存しておくような媒介サービスはたくさんあるけれど、これがブラウザ上でユーザーの手で実現できるところまでブラウザは進化すべきだと僕は考えています。ここからが競争。

プログラマとして生きるということ

はてなを眺めるようになってから、「IT土方（どかた）」という言葉を知りました。IT土方とは、

システムエンジニア、プログラマーなどにおける過酷な労働条件を自嘲的に表現したもの。「土方」は差別用語及び放送禁止用語として扱われているため、使用の際には留意すること。

という意味だそうです。僕は研究者だけれど、プログラマでもあるので、プログラマが世間でこう呼ばれているのは非常に悲しいことです。プログラマというのは、本当はとても魅力的な仕事です。土方で甘んじているのは、きっと「プログラマ」として生きていないのだとも思います。（例えば、矢野勉さんのエントリにも挙げられているような状況の人達です）


プログラムをデザインする、ということ プログラムの場合、通常の土木工事と比べて顕著に違うのが、一度作ったコードを「一から作り直さないようにデザインできる」ということ。たとえば、コマンドライン引数を処理するプログラムを一度作ると、それをクラスの形に整理して（OptionParserクラスなどと名づけて）ライブラ リにしておきます。ライブラリを作る作業は、Windowsならdllを作る、JavaならJARファイルにまとめることに相当します。

書いたプログラムが自動的に再利用可能になるわけではなく、そうなるように「デザインできる」ということで、この間は結構違いがあります。二度目からは、ライブラリにリンクして使うので必要な仕事の量は格段に減りますし、使い道にあわせてライブラリの修正をしなくてはいけないことも多いですが、機能を改善し、使い勝手を向上できるというメリットがあります。修正に費やす時間は、今直すか、後で必要になってから取り掛かるか、という違い。Ruby on Railsのフレームワークも、Webアプリケーションで頻繁に書くようなコードをうまくライブラリ、モジュールにしていると思います。

プログラミングが肉体労働になりやすいのは、おそらく、このライブラリにまとめるという経験が不足している場合。Visual Studioでdllを作っておくだけで、ビルド時間や開発時間は短縮できるし、Javaならmavenを使えば、細かな修正を施したjarを頻繁にreleaseする作業が苦ではなくなります。PerlだったらCPAN用のモジュールを作るとか、RubyならRuby gems用モジュールを作るというところでしょうか。

他に考えられるのは、プログラマ自身が今書いているコードが二度目のコード（重複がある）と思っていない可能性。オブジェクト指向の考え方や、デザインパターン（クラスの組み方の過去の知見）を知らなくて、コードを再利用可能な形でまとめることに考えが及ばない、ということがありえます。Subversionやgitなどのソースコード管理ツールの存在を知らないと、再利用といっても、常にコピー＆ペーストするという最悪な方法を採っている人も多いかと思います。これでは単純労働となっても仕方がない。


ハッカーと画家 ここで紹介したいのが、「ハッカーと画家」という話です。ソースコードを書くのは、絵画を描くのと非常に似ています。僕自身もそうですが、新しいものを創ることだけでなく、良いコード、簡潔でわかりやすいコードをデザインすることに魅力を感じます。本文中には以下のように書かれています：

ハッカーと画家に共通することは、どちらもものを創る人間だということだ。作曲家や建築家や作家と同じように、ハッカーと画家がやろうとしているのは、良いものを創るということだ。良いものを創ろうとする過程で新しいテクニックを発見することがあり、それはそれで良いことだが、いわゆる研究活動とはちょっと違う。

コードをデザインする能力が、画家の画力と同じように、良いプログラマたる条件でしょう。良いデザインを考えることはかなり高度な知的活動になります。ただ、ビジネスモデルの中で、プログラマが良いデザインをすることと売れることが直接結びつくケースは少なく、プログラマが労働過多になるのは、以下のような事情によるものかと推察します：

Yahooに入ってみたら、彼らにとってハックするということはソフトウェアを実装するということで、デザインするということではないということがわかった。プログラマは、プロダクトマネージャのビジョンとかいったものをコードへと翻訳する技師とみなされていたのだ。

究極のプログラミング - コンパイラを作る-　コードをデザインする時間・許可が与えられない場合、たとえば、コンパイラを作る、なんてことは到底認められないでしょう。けれど、コードを書くというのは、人が考えていることを機械が実行できるようにすること。この意味から考えると、究極のプログラミングはコンパイラを作ることにあります（お絵かきソフトなど人の入力を画像データにするのも、ある意味コンパイラですね）。簡単な記述で、素敵な仕事をしてくれるのがコンパイラです。コンパイラを作る時間、そのために必要な技術を習得するコストが大きいので、通常は、他人が作った言語やフレームワークを使ってコードを書いているだけです。

Webアプリケーションのように、どのOS、どのブラウザでも動くコードを書くのは大変です（主にIEが他とケンカしてしまう悪い子なので…）。だから、その作業を軽減するために、Google Web ToolkitではJava言語からJavascriptコードを生成するコンパイラを作るという、とても良い仕事をしてくれました。けれど、コンパイラを作るのだって、そんなに大変なわけじゃないですよ？以下は、Joel on Softwareより引用：

Most people don't realize that writing a compiler like this is only about 2 months work for one talented person who read the Dragon book. Since the compiler only has one body of code to compile, it is much easier to write. It doesn't have to be a general-purpose compiler. It doesn't have a math library, for example.　（多くの人が、コンパイラを書くのはドラゴンブックを読んだ優秀な人が2ヶ月くらいでやる仕事だってことをわかってない。コンパイラには、コンパイルするコードしかないので書くのは簡単だし、一般的なコンパイラなんて書く必要はないんだ。数学ライブラリなんてものもいらない。）

ドラゴンブックはコンパイラの教科書としてとても有名ですが、隅から隅まで読む必要はなくて、字句解析、構文解析の概要を知って、Lex/Yacc/Bison, ANTLR、JavaCCなどどれか1つのツールの使い方を学べば、コンパイラはすぐにでも作り始めることができます。

開発するプログラムが同程度のものなら、フレームワークなり、コンパイラがあるだけで相当仕事が短縮されるはずです。ここで負荷が減らないなら、コンパイラで仕事が簡単になったから、あれこれ追加機能を実装しようと欲張るなど、開発すべき仕事が単純に増えているのでしょう。逆に、コンパイルコマンド１つで製品ができても、それを1分、1秒の時間単価や人月で見積もられてはいけないのだと思います。

プログラミング＋αの時代　 インターフェースのデザインなどは、上記の「ハッカーと画家」の例のような比較とは違って、本当に「画家」とか「デザイナー」の能力を要する分野に踏み込んでいるので、プログラマの仕事としては過負荷になっているのだと思います。

僕は、デザインすることは昔から好きだし、コミック、油絵とかも良く描いていたので、ウェブデザインをするのは時間はかかって大変なことだけれど、楽しい部分として受け入れることができます。まだまだ未熟だけれど、デザイン＋コーディングの両方できるというのは僕自身の専売特許だと思います。データベースが専門でシステムを作れるというのも、プログラマとして持っている僕の付加価値です。プログラマは、コードをデザインするだけでなく、＋α（アルファ）の部分で、自身のブランドを作れる存在だと僕は思っています。売れないブランドだって当然でてくるわけで、オープンソースのApacheブランドだって、よくよく見てみるといいコードばかりではありません。

プログラムをデザインする能力を習得した上で表現すべき「＋α」の部分が、まだまだ未開拓のように感じています。コンピュータ専攻の人だけでなく、もっといろいろな人にプログラムを学んで欲しいと思うのです。自分の魅力である「＋α」をアピールするためにプログラムを作ってみる、知識が足りなければプログラミングを学ぶ、この繰り返しをするのがレベルアップへの近道でしょう。

プログラムやコンパイラを作るというのは大変なことですが、「魅力的なものを創る」ためには欠かせないことです。コンピュータ、インターネット内だけの話ではなくて、コンピューターでデザインして、現実の作品を作るなんてこともできます。せっかくプログラミングという応用分野が広く、すばらしい技術を学んだのに、人に言われたものだけ黙々と作るというのでは、面白くないのは当然。

プログラマが「＋α」を作るという意味で、作ったものが売れないことがあるのも、飛ぶように売れる（有名になる）ことがあるのも、作家や画家と似たものを感じます。それはプログラマという職そのものの性質ではなくて、ビジネスとしてブランドの宣伝であったり、市場があるかどうかなど問題だと感じます。プログラマも、作りたいものだけを作る、と小説家や芸術家くらいわがままであってもいいと思います（これは偏見ですが）。わがままを通して「食える」ようになるというのは、プログラマに限らずまたどこか別の次元の話です。

プログラマとして生きるということ　プログラマとして生きていくというのは、ビジネスを含めて、自身のブランドとして独立する覚悟が必要ですし、そうしない道を選ぶなら、他で生活の糧を得る必要があります。これは、プログラマとして能力が劣ることを意味するわけでも、恥ずかしいことでもありません。Googleだって広告収入が安定しているからこそ、Google Web Toolkitなどの開発に注力できているのです。

開発をしていて労働過多で見合った収入が得られていないと感じたときに、「プログラマだから」と結びつけるのは、誤った思い込みであるように思います。「プログラマ」とはそんなひとくくりにできるような言葉ではありません。「プログラマ」は好きなものを思いのままに作れる夢のような職業である一方、製造・出版業のような既存のレールがない分、ものをつくる職業として確立できていない難しさもあるでしょう。

けれど、そんな時代の荒波を生きていくのが「プログラマ」です。数年で技術が変わり、新しいツールも次々に出てくる。そんな中、目指すものを創るために、自ら学ぶことを止めず、成長し続ける人が、真の「プログラマ」と呼ばれるべきです。3年前にも同様のことを書きましたが、プログラマやハッカーという言葉に対するこの思いは今でも変わっていません。

JARファイルの中にJARを埋め込む

以前、「Leo's Chronicle: Fat Jar: Jarファイルの中にJarを埋め込む」で、JavaでFatJar plug-inを使って、Jarファイルの中にJarを埋め込む使う方法を紹介したのですが、最近は事情が変わってきています。

たとえば、Eclipse3.4からは、Runnable Jarの作成がサポートされ、依存関係にあるすべてのJARファイルの中身を展開して、1つのJARにまとめてくれる機能が標準装備だったり、Mavenユーザーなら、assembly pluginを使って、jar-with-dependenciesを指定する方法もあります。

ぱっと試したいなら、Runnable Jarを作成するのが速くて楽。このようなJARを頻繁に作成するなら、Mavenのassemblyで書いてしまうのが良いです。

関連記事：JARファイルの作成方法

[本郷でお散歩] UT Cafe

(長かったので前エントリを分割しました）

久々に本郷をお散歩してきました。東大の本郷キャンパス周辺のアカデミックな雰囲気がとても好きなんです。カフェに入ってもなにやら難しそうな英語の文献を読んでいる人が多かったりと。今日は、新しくできたUT Cafe（赤門入ってすぐ）に行ってきました。


最近の東大はとってもおしゃれですね。店内も赤をアクセントに使ったりと、表参道の通りのカフェみたいな雰囲気。お茶をしながら、研究のことを考えノートに マインドマップを描いていました。何もない静かな部屋に一人でいるよりも、人の動きのある中で自分の場所が持てるカフェのような環境の方が、かえって集中 できるので好きです。

博士課程のころは、部屋に一人ぼっちで寂しいことが多かったので、その孤独を乗り越えるためにカフェの存在は必須で した。最近はカフェで作業することもほとんどなくなったので、昔を懐かしみつつ、ノートひとつで、０から研究の全体像を描きなおしてストーリーを練り、今 後何をつくるとよいのかを自分の中で整理していました。

普段と仕事中としていることとほとんど変わらないのだけれど、休日だからと欲張ら ず、少し環境を変えて、普段＋αくらいのことをするのが、お休みの有意義な楽しみ方だなと思います。本当は、休みになったからDBMSをじっくり作れる！ とか思っていたりしたのですが、大きなことは「一日にして成らず」です。大規模なシステムは少しずつ進めていかないと、作りきれません。

[本郷でお散歩] PFIに行きました

今週休みをとっていたので、この機会に、はてなの関連エントリー機能を実装するなど、いまを時めくPreferred Infrastructure(PFI) さんに遊びに行ってきました。忙しいところ快く応じてくれた社長の西川君、太田君に感謝。


以前、二人が会社を立ち上げたばかりのころに、データベースの話で盛り上がったことがあります。東大全体を見回しても、データベースシステムとその実装にまで興味がある人って意外と少なくて、Jim GrayのTransaction Processingを読んでいるなど、データベース屋さんの僕にとっては、貴重な話相手です。

ACM主催のプログラミングコンテストICPCの東大内予選（と僕が勝手に呼んでいます。本当は国内予選。ただ、各大学から３チームまでしか先に進めない）を勝ち抜けて、世界大会にまで出場するだけでもすごい人達なのですが。

今日は分散トランザクションについて話をしてきました。トランザクション処理は、スループットを上げるための実装はそうとう複雑なのですが、さらにマシンが複数台になると考慮すべき障害が増えてとたんに難しくなります。運用を考えたときのコストとか、商用DBといえど落ちることがある、などの話を聞けてためになりました。僕は研究者の立場なので常に新しいものを開発すればいいのですが、24時間常時動かすというのはやはり相当大変なことなのだと再認識。もしかすると、僕はこういった運用の大変さから逃れるために、研究の道に入ったのかも。

今回は短時間の訪問だったので紹介しきれませんでしたが、本当は最先端の話題でもっといっぱい話したいことがありました。主にMITのStonebraker教授(PostgreSQLを作った先生）のお弟子さんたちの話なのですが、C-Store (列ごとにテーブルを分割して圧縮。性能抜群）, H-Store (トランザクションの意味を考えて、仕事の単位を分割、sequentialに処理して速度を稼ぐもの)など。One-size doesn't fit all (DBMSも用途に応じたものが必要）という時代の流れがあるんですね。現在主流のrow-oriented storage（テーブル行単位でディスクに配置していくもの）で、ロックマネージャーを外し、ログを外し、、、とやっても、トランザクションで100倍の性能を上げるのは難しいんです (OLTP Through the Looking Glass, And What We Found There. SIGMOD2008を参照)。

まだ教科書には載ってないけれど、トランザクションを高速に実現するための現在の主流であるsnapshot isolationを、性能をほとんど落とさずserializableにする話 (Serializable Isolation for Snapshot Databases。著者に実際に会ったときにソースコードくださいと話したらBerkeleyDB上での実装を公開してくれました)など。

XMLのような階層構造のデータもrelational databaseと同じ枠組みで扱える、という僕の研究の話もいつか紹介したいですね。こんな要素をもろもろ含んだ日本発の最先端DBMSを、彼らのように物を作ることに貪欲で、「わくわく」する感覚を持ち続けている人たちと一緒に作れたらいいなぁと夢見ていたりします。

PFIのオフィスは、自宅から徒歩圏内なので、本当はもっと遊びに行きたいのですが、職場まで遠距離通勤＋子育て中なので、もうちょっと落ち着いてからかな。

後編：[本郷でお散歩] UT Cafe にも行きました。

良い論文を書くために知っておくべき５つのこと

英語で科学技術論文を書くための書籍はいくつか出版されていますが、大抵、日本語と英語の表現やロジックの違いの説明が主で、「論文」というよりは「英語」の学習と質的に変わりません。ここでは、「論文」をいかに書くか、さらには「論文」を書くために「研究」をいかに進めるかという点に踏み込んだ内容を紹介していきます。

まず、コンピューター系の論文の書き方のHow toを示した書き物として、DB分野で有名なJennifer Widomの以下の記事が、良い指針となります:

• Tips for Writing Technical Papers (Jennifer Widom)

この中から、introduction (導入部）で説明すべきことについて引用しました。

• What is the problem? (解いている問題は何?）
  
• Why is it interesting and important? (なぜその問題が面白くて重要なの？)
• Why is it hard? (その問題のどこが難しいの？ 簡単な方法で解けないの？）
• Why hasn't it been solved before? (なぜ今まで解かれてなかったの？)
• What are the key components of your approach and results? (あなたの仕事のどこが重要なの？）

１. Abstract, Introductionが９割を語る

論文査読では、自分と同じ専門分野の人に巡り会えることは稀です。むしろ専門外の人に読まれるのが通常で、あうんの呼吸で問題が伝わる、なんて信じることに意味はありません。皆がコンピューターに触れるようになって、コンピューターサイエンスの分野も相当広がってきました。それに伴い、論文と同じ研究テーマに洞察の深い専門家に当たる確率も相当低くなっています。XMLの論文だからXMLに興味がある人向けに書く、ではなく、コンピューターサイエンスをかじった程度の人でも、abstractを読んで「XMLにはそういう性質があるのか、なるほど。面白そう！」と思えるように説明するのが大切です。上に挙げた５つの項目がintroductionで綺麗に説明されていない論文は、僕が査読した論文や、自分が過去に書いた論文も含めて、十中八九、いい論文（つまり読みやすい論文）にはなっていません。introduction以降の文章はろくに読まれないか、書いた本人の意図やアイデアがうまく伝わらず、見当違いの評価が返ってくるのが落ちでしょう。

2. コードを練るより先に、伝えるべきことがある

コンピューターサイエンスの分野においては、良いものを作るのはもちろん大事なのですが、そこから「良い論文を書く」までの間には相当な壁があります。日本では、この「良い論文を書ける」域に達している人が、欧米、さらにアジア圏内で見ても、圧倒的に不足しています。DB分野では既にシンガポールの方が論文を書く力は日本より優れているようです。技術的には、日本人でも、アルファギークと呼ばれるプログラマが多くいたり、未踏ソフトウェアでスーパープログラマと認定される優秀な人がいますが、必ずしも彼らが研究の世界でプレゼンス（存在感）を発揮しているわけではありません。(DBLPから氏名を検索すると活躍の度合いがわかると思います）

この壁の正体は何か？ コードを書ける人が陥りがちなのが、文書よりもコードを改善してしまうという罠です。作りあげたコードには、いろいろなノウハウや、論文に書ききれないくらいたくさんの最適化のための改良が施されていることでしょう。うまくいけば、決して他の人には作れないユニークなものが出来上がります。でも、ちょっと待って！論文は人に技術、アイデアを伝えるために書くもの。そんな人が真似できないものを作ってどうするの？

システムが複雑で、性能評価にいろんな要素が入ってくるほど、他の人が利用できない（つまり後続が現れない）研究になります。オープンソースの世界と同じで、研究の世界でも、人に面白い問題、アイデアを提起してあげると、あとは周りが勝手に問題を読み取って、後続研究が広がります。そんな動きを触発するには、コードを練るのと同じか、あるいはそれ以上に文章を練ることが大切です。アイデアを一番伝えられるのは、何よりもまず文章です。

３. 良い文章とは、悪い文章を書き直したものだ

最初から良い文章を書くことの難しさは、物書きなら誰もが直面する課題ではないでしょうか。良い文章がすらすらでてくる人が天才なら、そうでない自分は物書きには向いていない。そのような思考に陥りがちだった僕を十二分に救ってくれたのがこのフレーズです。

引用元のGood Writing by Marc H. Raibert には、文章を書くテクニックというよりは、書くために必要な心構えが記されています。kunishi先生のブログでも紹介されていますが、そもそもRaibertの文章そのものが、"Good writing is a bad writing that was rewritten (良い文章とは悪い文章を書き直したものだ)"の実例となっているのですね。

４. 書いた文に振り回されるくらいなら、思い切って捨てなさい

これも上のRaibertの記事から。文章を書いていると、とても良い文が書けたと思うことがあります。ただ、書き進めていくうちに、その文が周囲の文章と合わなくなったり、伝えたいことと内容が離れてしまうことがあります。でも、せっかく書いた名文は生かしたいというのが人情。

そんな文章の断片があちらこちらにでてくると、頭の中では文章という複雑なパズルのピースを組み合わせる作業が始まってしまいます。文章のニュアンスであり、既に説明した情報であり、いろんな要素を頭の中で組み合わせて文章を書くことになります。プログラムを組み立てるときも似たようなことが起こりますが、文の与える印象の方がより抽象的な部品なので、相当難しいパズルを解くことになります。

そういうトラップにはまったなと感じたら、その名文の部分を思い切って捨てます。さすがに、ただ消し去るというのでは忍びないので、PRIZE_WINNING_STUFF.txt （これは賞を獲れる！）というファイルに貼付けて保存して置きます。パズルのピースが減って、伝えたいことに絞って文章を書くだけでよくなるので、驚くほどの効果があります。必要なら、あとで「賞を獲れる名文」を戻してもいいでしょうが、僕自身の経験で、ここから復活したフレーズはありません…。　

PRIZE_WINNING_STUFF.txtは、最終的にほとんど役に立たないにも関わらず、論文を書くときにこれほど役に立つ道具はありません。

5. 良い研究でもシンプルなアイデアでできている

難しい研究に見えても、根本的にはシンプルなアイデアでできていることがほとんどです。論文の格を上げるために、式の定義を小難しく見せる必要はありません。問題解決のアプローチがシンプルであっても構いません。問題を解くことで分野の研究を一歩進める、そしてその成果をわかりやすく伝えることが何よりも大事です。

これを説明するのには教科書が良い例だと思います。教科書というのは、その分野をよく理解した人が、技術の内容を噛み砕いて、わかりやすく説明したものです。その最たる例として、DB分野には、現在のトランザクション管理には欠かせない技術であるARIES (WAL: Write-ahead logging)の論文があります。この論文は、分量も多くDBをよく知っている人でも読みこなすのは大変なのですが、教科書になると１ページで、アイデア自体もとても平易にまとめられる内容です。教科書というのは、元は論文であった知識を短く、かつ、技術を再現するのに十分な情報を持っている文章です。簡単だからといって、重要でないわけではありません。

では、噛み砕けばシンプルなアイデアをいかに論文として仕上げるか？ 重要なのは、シンプルなアイデアを素直に説明できる力にあると考えます。

先ほども述べましたが、日本ではプログラミング能力はあるけど、PhDをまだ取っていない（あるいは取る意思のない）若手が注目を集める一方、グーグルでは、PhDを取得した人を積極的に採用しています。プログラムの力量という意味ではPhD自体は意味を持ちませんが、PhDが示すのは、論文を読んで最新技術の詳細を理解でき、その上で、「新しいものを作り上げる力」を持っているという証です。過去を知らずして「新しいもの」は説明できないし、意図的に「新しいもの」の開発もできないでしょう。「新しい」は常に過去の技術との比較です。過去の論文で、問題がどのように定式化されているかを知っていることも、アイデアを簡単に伝えるためには必要です。

また、アイデアやアプローチがシンプルであっても、対象としている問題が重要で、解くこと、調べることに価値があれば、それは立派に「研究」として成立します。そして、この対象とする問題の重要性を考えることが、冒頭に挙げたintroductionに書くべきこと（問題設定、なぜ重要か、問題の難しさ、過去の研究との比較）に反映されていきますし、introductionを書いたときに、不足している実験が見えてくることもあります。このサイクルが研究の進める上で非常に大切です。

ACMのSIGに代表されるコンピュータ系のトップ会議に論文を通すためには、五十嵐先生の記事にあるように、もう少し努力や工夫が必要なようです。喜連川先生もインタビュー記事で語っていますが、そのようなトップの国際会議では３回くらいrejectされるのは当たり前で、落とされたからといって、がっかりしすぎてもいけないようです。さらに、いい研究ならば２番手の会議はスキップして、トップの会議に出すまで１年くらいsubmitを控える（！）なんてこともあるようです。

最後に、大前提として再びGood Writing by Marc H. Raibert から。

良い論文を書こうと思うこと、そして、書けると信じること

これがなくては、先に進めません。書く力は年をとっても伸び続けると聞きます。あきらめないことが肝心です。

Rails、Hibernate、EJB スキーママッピングあれこれ

久し振りの更新。普段、突発的にものを書きたくなる衝動をブログにぶつけていたのですが、最近はそれがTwitterに吸収されてしまっています。短い単発コメントより、まとまった文章がある方が本当は価値が高いんですけどね。今日はTwitterが重いので、ブログに戻ってきました。

閑話休題。

SIGMOD2008に参加してみて不思議だったのは、Schema Mappingの研究が想像以上に盛んだったこと。これは、データベースのスキーマ（テーブル構造情報）を、他のスキーマへと変換するときに使います。データベースの移行とか、アプリケーションに合わせて形を書き換えるとか。

でも、そもそもマッピングって、足し算が入るだけでも、不可逆変換なんですよね。1+2を合わせて、「3」というデータを作ったとき、この「3」というデータは、1+2の結果か、2+1の結果かわからなくなる。そうすると、マッピングに使える演算の種類は限られてきます。

SIGMOD2007のベストペーパー、Compiling Mappings to Bridge Applications and Databasesにあるように、テーブルデータ　-> オブジェクトというマッピングをし、オブジェクトの更新結果をテーブルデータに正しく反映させるといった、roundtrip制約を入れると、使えるマッピングの種類を限定せざるを得ません。Join演算なんてもってのほかです。

問題を、オブジェクト（Javaのクラスなど）とテーブルデータ(relational database)の構造の違い(impedance mismatch)の吸収に絞ると、すでに世間で実用化されている技術がいくつかあります。Ruby on Rails, EJB3.0 (Enterprise Java Beans), Hibernateなどがその代表でしょう。

それぞれの一長一短(pros and cons)

Rails: テーブルの列名に対応したメソッドを自動追加するので(Person.id, Person.name, ...などでアクセス)、簡単なスキーマ変更（カラムを増やす、など）なら、ソースコードの変更が不要。ただし、実行時に初めてわかるメソッドなので、コンパイラによる静的チェックの恩恵が受けられない。実際に、動かしてみるまでプログラムが正しく動くかどうかわかりません。

EJB3.0: Javaのクラス定義と、テーブルデータをAnnotationなどを駆使して対応させます。テーブル名、カラム名とクラス名、メソッド名が食い違う場合はAnnotationを使って細かい対応付けができるのが売り。Data Access Objectを通して、オブジェクトを更新、テーブルに反映させるという手順。ただし、１つのオブジェクト定義でも、文脈に応じて、別々のテーブルに格納したいことがあります。たとえば、Personクラスを、student, teacherテーブルへ。student（Personクラスに対応）の一部を、alumniテーブルに格納したい、などなど。クラス定義の中に対応するテーブル名やカラム名を含める設計だと、この目的には対応できません。ここはぜひ分離してほしいところ。（Railsも、クラスに対応するテーブル名は決め打ちです。プログラミングはとても簡単な反面、オブジェクトの使いまわしは難しい。一応、オブジェクトに対応するテーブル名は設定可能ですが）

Hibernate： 僕はこのtutorialを読むだけでがっかりしました。こちらにも解説書のサンプルがあります。Javaのクラスと、テーブルデータベースの違いを吸収するのに、XMLで書かれたマッピングファイルが必要なんです。EJB3.0も裏でHibernateを使っているようです。なんだ、なんだ？。これだと、クラスを書き換えたら、XMLも書き換える必要がある。そのXMLファイルをクラスファイルから自動生成できるのかもしれないけれど、Javaのリフレクションを使えばXMLをあらかじめ用意する必要なんてないはず。設定ファイルが多い（ある）という点で、Railsほどの簡潔さ、わくわく感はありません。


明示的であれ暗黙的であれ設定項目を把握するまで動作が理解できないスキーママッピングなら、技術としての重要性は低いように思う。Railsのようにマッピングを決め打ちできる状況は多いと感じるし、テーブル型データとオブジェクト間のimpedance mismatchがそれほどあるとも思えません。現に、Object-Relational Databaseというように、Reational databaseは、様々な形のオブジェクトを保存できるように成長しています。


データベースのデータを扱うのが、プログラム言語中であるなら、プログラム中で使うクラス定義（オブジェクト）がスキーマそのものです。オブジェクトをそのまま保存できれば事足ります。テーブル名、カラム名なんてプログラム中で気にする必要はないはず。それに加えて、オブジェクトをどのような位置（コンテキスト）に保存するかが選択できればよい。たとえば、2007年度のデータ、2008年度のデータなど、フォルダでファイルを管理するのと同じように、データを保存する位置を決める。この2点ができれば、データベースの機能としては十分なんじゃないかと思います。

コンテキストを表す能力が高いのはXMLだし、定型データを扱うのはRelational Databaseの得意技。データベースの研究者として、両者の融合をもう少し進めていきたいところです。

研究者インタビューを受けました

SIGMODに論文が採択されたこともあって、インタビューを受ける機会がありました。(電子情報通信学会 データ工学研究会のニュースレター)。

インタビューと編集はNTTサイバー研の鬼塚さんがしてくれたのですが、本当にお疲れ様です。普段SIGMOD Recordなどで研究者インタビューを読む分には気楽なのですが、いざ自分が受けてみたり、編集の様子などを見ると、裏では、相当な努力があることがわかりました。

鬼塚さんの努力の甲斐あって、今回が初回のニュースレターは、かなり読み応えのあるものになっています。喜連川先生のアドバイスには、研究者として大事なことがたくさん含まれてい ます。top confereceを目指すことは重要、でも、研究者としてできることは、それだけではない。

小杉さんのＰＣ(Programming Commitee)体験談でも、immediate rejectは本当にあっさりしているんだな、と。また、今回のSIGMODのPC ChairであるDennis Shashaが提示したという査読、採否の方針はとても参考になります：

1. 査読にあたってはそのペーパの良い部分を見つけるように心がけること。rejectする際は、技術的な誤りなどの正当な理由や、killer referencesを示すと共に、some words of encouragement を忘れないこと。
2. innovative ideaを重視し、短期間で修正可能なミスを主原因としてrejectしないこと
3. 既存のアルゴリズムのバリエーションで、ちょっと思いついた、程度のものは、大規模な性能改善がない限りあまり重視しないこと
4. 実験に関しては、
　i) 統計的に意味のある母数で実験がおこなわれていること
　ii) 可能な範囲で標準的なデータセットとクエリを用いていること
　iii) 更新とクエリシナリオがテストされていることが満足されていることを重視すること

それにしても投稿数が去年の3割増しとは。。。PCも大変だ。論文を投稿するときは、読みやすい論文にすることを心がけて、PCの負担を減らしてあげるようにしないといけないですね。また、自分が査読する側に回った際も、良い部分を見つけるようにして、研究コミュニティの良いサイクルを回していくことがとても大切。

結婚

友人の結婚式に参列しました。

自分以外の結婚式に参加するのは初めてでしたが、料理も美味しいし、それぞれの催しに新郎新婦の思いがこもっていて、本当にいい結婚式でした。

こちらがお祝いするのはもちろんなのだけど、それ以上に向こうから幸せをたくさんもらったように思います。結婚式って、こんなにいいものなんだと実感。妻を大事にする気持ちの大切さを再認識させられました。

前日まで、スピーチを考えて練習したり（本番は、インタビュー形式で、司会の人が助けてくれたので拍子抜けしましたが。。。）着ていくものを準備したり、子供がいるので、買い物に行く時間がなかなかとれなくて、かなりばたばたしていたけれど、間に合ってよかった。


披露宴では、スクエアの懐かしい曲！（Sweet Sorrow）に乗せて、新郎が自分で作成したという、写真のスライドショー。自分も一緒に移っているサークルのコンサートの時の写真を乗せてくれて昔を思い出せました。

彼自身もピアノを披露してくれました。いつの間に！と驚くとともに、何故か負けないぞ！という気分にもさせられたり。何を競ってるんだかわからないけれど(笑）環境が変わるにつれて、エレクトーンも昔のようには弾かなくなってしまっているので、再開するにはいい刺激になりました。

結婚式、自分ももう一度したいな！と思わされたけれど、一度だからこそ思いを注げるし、いいものになるんですよね。昔の友人にも再会して話も弾んだし、至福のひとときでした。

あなたの大切なファイルに、突然「さよなら」と言われないために

三浦しをんさんのブログを眺めていたところ、彼女の原稿ファイルが壊れてしまったという話がありました。小説家にはとっても痛い話でしょう。そんな悲劇を少しでも防ぐために、ファイルの変更履歴を管理するためのシステムSubversionについて、以前に僕が書いた簡単な使い方のページを紹介します。

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

情報系学生向けの内容なので、英語で、しかもコマンド入力形式を前提に書いているので、一般のパソコン利用者には読んで理解するのは大変かと思うのですが、こういうものがあるんだよということをぜひ知ってもらいたいです。

Windowsなら、TortoiseSVNという、マウスクリックで使えるSubversionもあるので、こちらをインストールして使ってください。

簡単な概念の説明

• 適当な位置に、リポジトリ(repository)と呼ばれるものを作ります。これは、あなたのファイルとその変更履歴を保存するデータベースのようなものです。
• 普段の執筆作業、ファイルの編集等は、ワーキングコピー(working copy)と呼ばれる、リポジトリの中身のコピーに対して行います。ワーキングコピー内のファイルをいくら編集したり、削除しようと、リポジトリには影響を与えません。
• ワーキングコピーを作成するには、まず、チェックアウト(checkout)という操作を行い、リポジトリからあなたのファイルのコピーを取り出します。
  
• ワーキングコピー上のファイルの編集結果を、リポジトリに反映させてもいいと判断したら、コミット(commit)と呼ばれる操作を行い、ワーキングコピー上での編集内容を、リポジトリに送ります。
• ワーキングコピー上の新しいファイルは、自分でリポジトリに追加(add)する、と選択しない限り、リポジトリには送られません。
• リポジトリには、コミットする前と後のファイルの内容がすべて記録されています。従って、一ヶ月前の原稿を取り出したい、という要求にもこたえることができます。1回のコミットごとに、リビジョン(revision)の番号が更新されていきます。
  
• ファイルを元に戻したい、というときには、リポジトリから復元(revert)操作を行います。誤って消してしまったファイルや、修正結果などを元に（リポジトリに保存されている状態に）戻せます。
  
• 定期的にリポジトリのエクスポート(export)を行って、最新の状態のファイルのバックアップをDVDなどの外部メディアに保存しておくと良いでしょう。更新履歴を含めたリポジトリ全体のバックアップが必要なときは、svnadmin dumpコマンドを使えるように設定する必要があります（詳細は公式ページや、onlineのsubversion解説書で）。

（サーバーに設置するとき）

• リポジトリは、Webサーバー上に作成するといたるところで自分のファイルにアクセスできるようになるので、利便性が高まります（Apache + mod_dav_svnなど）。あるいは、sshログインできるサーバー上に、リポジトリを作っておくと設定要らずで簡単です（svn+ssh://(server address)/home/leo/svn/repository というようなURLでアクセスできる）。
• Webサーバーなんて設置できない、という人は、最近はUSBメモリが大容量化しているので、こちらにリポジトリを作成してもよいのかもしれません。ただ、盗難、紛失によってデータを失うリスクが高いので、あまりお勧めできません。
  
• 複数の人（自分一人の場合でも、自宅、会社のPCなど）のコミット後の更新結果を手元のワーキングコピーに反映させるには、更新(update)を実行します。自宅と会社で同じファイルを編集してしまった場合は、コミットや、更新を行ったときに警告が出されます。両者の変更を簡単に合成(G: merGed)できるときもありますが、そうでないときはC（Conflict）マークが出ます。その際は、手作業で更新がぶつかった箇所を編集して、conflict resolvedという操作を行わないと、そのファイルはコミットできなくなります。人の更新結果を使って、手元の更新結果を無視して上書き、なんてこともできます。

何箇所かのPCにワーキングコピーが残っていれば、いざリポジトリが入っているディスクが故障したときでも、ワーキングコピーから新しいリポジトリを作ればいいだけなので、完全ではないとは言え、ラフなバックアップ効果があります。

文章やプログラムを書くという作業は、もうSubversionがないと怖くてできません。でも、世の中の大半の人は、まだこの恩恵にあずかれていないのかと思うと、少し悲しくなってきます。リポジトリの置き場所、バージョン管理って何？という面で、やや敷居が高いのですが、 あなたの大切な「パートナー」のことですので、真剣に考えてあげてくださいね。