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

三浦しをんさんのブログを眺めていたところ、彼女の原稿ファイルが壊れてしまったという話がありました。小説家にはとっても痛い話でしょう。そんな悲劇を少しでも防ぐために、ファイルの変更履歴を管理するためのシステム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がないと怖くてできません。でも、世の中の大半の人は、まだこの恩恵にあずかれていないのかと思うと、少し悲しくなってきます。リポジトリの置き場所、バージョン管理って何？という面で、やや敷居が高いのですが、 あなたの大切な「パートナー」のことですので、真剣に考えてあげてくださいね。

大学の若手研究者ができる４つのこと・実践編

情報関連の研究では、日本は欧米を中心としたコミュニティから取り残されています。このことは、ここ数年のTop Conference/Journalでの日本のpresence（存在感）をみるだけでもよくわかります。この状態を危惧して、tatemuraさんが「大学の若手研究者ができること」と題して以下の4つを提言しています。

（１）英語のレジュメを書いてみる（書かせてみる）
（２）日本語論文を書かない（書かせない）
（３）無駄な学会を退会する
（４）官僚との付き合いを減らす

「日本語論文を書かない」という点については、僕自身、既に6年実践しています。そもそも、東京大学 の情報科学科というところ（大学院ではComputer Scienceという名称）は、学部の卒業論文から英語で書かせる伝統があって、英語で論文を書くということは、研究をする上でのボトムラインという感覚が染み付いています。この意味では、「英語で書かせる」というのは、教育的にはいい方法だと思います。

東大生と言えど、皆が英語が流暢なわけでも、英文を書き慣れているわけでもないので、最初に出来上がってくる文章はひどいものですが、経験を積んでいくと、だんだんいい文章が書けるようになってくるようです。ここで苦労している時点で既に、英語圏で普通に研究をしている人たちに差をつけられているので、日本語で書く暇があったら、日頃から英語で書く練習をしないと、ますます差がついてしまいます。

tatemuraさんも言っていますが、日本人の頭脳や技術力が必ずしも劣っているとは、僕も思えません。（とある先生に同じ話をしたところ、向こうの研究者はもっと賢いんだよ、と言われましたが（汗））。それはともかく、新しい技術や、自ら開拓した研究分野を、「英語」で「わかりやすく」伝える技術を併せ持った人が、日本にどれだけいるのでしょうか？ という話です。SIGMOD, VLDBのようなデータベースのtop conferenceに通すためには、英語のnativeと言えども、数ヶ月を書けて論文を、個々のフレーズに至るまで吟味するそうです。ミーティングで文章を議論して、２時間でようやく1パラグラフ進んだという話も聞きます。僕としても、「日本語で書かない」を実践した、というよりはもっと単純な理由で、「日本語でまで論文を書く余裕がない」というのが本音です。

研究者として、一番面白くないことは、自分の仕事（論文）に対して何も反応がないことだと思っています。ブログを書く動機だったり、絵や音楽などの作品を作る情熱だって、何らかの反応を求めてるから生まれてくるものだと思います。ビジネスだったら、売れる、ということ。だから、たとえ論文が採録されたとしても、Reviewerの反応が素っ気なかったり、後続研究が出なかったら（つまり売れなかったら）がっかりするものです。（ブログに関しては、直接のコメント等がなくても、のちのち、いろいろなキーワードで検索されていることを知ると楽しいものですが）

日本語でわかりやすく研究を伝えるのも大事な仕事ですが、それはどう頑張っても日本の閉じたコミュニティでしか売れないことを覚悟しないといけません。読む側の立場から見ても、SIGMOD, VLDBの文献を追うだけでもかなりの労力を要するので、英語論文に決して引用できない日本語文献は、必然的に読まなくなっていきます。国際的に影響力のある人が、日本語で発表できているなら、世界の風が日本にも流れてきて良いのだと思いますが、現在のようにそのルートが閉ざされてくると、コミュニティは国内に閉じる一方なんだと思います。

ただ、研究者を目指す人にとって、日本における博士課程までの学生生活というのは必ずしも、経済的に恵まれたものではありません。比較的、財政的に豊かな東京大学ですら、博士課程の学生の授業料を全員免除するには至っていませんし、アルバイトをしながら、PhDや、職を得るために、通しやすい日本語で論文を書いている、という事情もあると思います。学生という理由だけで、保育園へ子供を入れる優先順位が他の人より下げられてしまうなど、社会全体として、世界最先端の研究者を育てる風潮がないのも確かだと思います。高校生までの教育問題は報道等で好き勝手に論じても、大学以降の、特に情報系の現在のようなpresenceの低い状態や、学生の待遇については、世間で議論されている様子はちっとも伺えません。

「無駄な学会を退会する」 は、まだ学会のPCを依頼されるような、一人前の研究者にはなっていないので、そういう身分になってから考えます。ただ、Fellowならまだしも、ただ の学会の会員というのには、どんな価値があるのかよくわからない、というのがあるので、メーリングリストを読む以上の会員にはなっていません。

「官僚との付き合いを減らす」というのも、まだ、どうコメントしていいかよくわからないところです。日本の劣勢を覆す土台となる学生の研究生活の改善のためには、社会的地位の低い学生として博士を取得する苦労を知っている人が、官僚となって働いている方が都合が良いと思うことが多々あるからです。むしろ、現状を鑑みる限り、もっと学者が参政しないといけないと感じています。

最後に、「英語のレジュメを書いてみる」という点。これが実践できていないことが、ここのところ心残りだったので、今日、自分のCurriculum Vitae (CV：履歴書)を書いてみました。海外の若手研究者と比べると寂しい限りですが（tatemuraさんの記事は、この寂しさを認識させたいという意図でしょう）、このCVを充実させ、常に世界に向けて情報を発信していくことを念頭に努力していきたいと思います。

SIGMOD 2008 Repeatability Assessment

今年のSIGMOD 2008から始まったRepeatability Assessment。論文中にある実験結果が第三者によって再現できるかどうかを確認する趣旨のものです。

実行可能なバイナリやソースコードを送り、実験結果を相手方のマシンで検証してもらいます。並列分散計算とか、マシン環境がないと再現しにくいものもあると思いますが、scalabilityとか、result sizeなどなら、傾向として一致することは確認してもらえます。

論文誌と同時に公開されるであろうコードを使って、比較実験がしやすくなるだろう、という期待はあります。他人のアルゴリズムを実装するのは常に大変なので。ただ、コードが入手しやすくなると言っても、フェアな比較になるように気をつけて（実装言語、applicationの違いとか）、かつ性能差の定性的な原因を明らかにしないと、研究としては面白くならないと思います。

ちなみに今回の評価は簡単なものでした。以下、抜粋。
-----
Overall repeatability : Strong Accept

Summary: Figures 16,17 and 19 were successfully repeated.

Details: Output (truncated because of the conference tool editing limits):
synth.tab
query fanout scale mode trial time
q5 2 1 0 1 0.125
q5 2 1 0 2 0.125
...

Were you able to install the software? : Yes
Were you able to run experiments? : Yes, all of them
Were you able to repeat experimental results? : Yes, all
Was the submission well-formed (valid and meaningful XML file etc.)? : Yes
----

実は、このfeedbackを得る前に、「プログラムが動かないよ」、という返事が来て、原因を調査したら、送ったコードに、Visual Studio C++ 2005 (SP1)の配布用DLLが含まれていなかったようです。慌てて返信したところ、無事プログラムが動いたようです。Visual Studioが入っていてもだめみたいで、SP1のDLLが必要だったところが盲点。今度から、仮想マシンで実験しておかないとだめですね。Javaだとこの類いの問題が少ないので楽なのですが。


実験を再現するためのMakefileやら、スクリプトを書くのは割と面倒だったのですが、意外なことにその努力の結果は自分に返ってきました。追加実験をするときに同じスクリプトが使えました。自分のプログラムの使い方の備忘録にもなっているし、後々になってわかる良いところが多数。

今度から、実験結果はSQLiteのDBにでも入れて、平均や標準偏差を取ったり、グラフを書く作業もgnuplotを使って、自動化できるようにしておきたいなと思いました。（今回は楽をしてExcelで書きましたが、自動化してなかったので書き直すのはやはり手間だった）

USBメモリからLinuxをインストール

PXEBootによるネットワークインストールでもいいけれど、CD/DVDドライブがないマシンの場合、このやり方も簡単。

まず、好きなLinuxのdistributionから、diskboot.imgをダウンロードしてくる。

ブートイメージをUSBメモリ（FAT32フォーマットしたもの）に展開
> cat diskboot.img > /dev/sdg1

/dev/sdg1 はUSBメモリなどのデバイス名+partition番号。
cygwinを使っている場合は、cat /proc/partitionsでどのデバイスが使えるか確認できます。

Linuxのインストールは、USBメモリをマシンに差し込む。起動メニューでUSBメモリを選択すると、Linuxのインストールメニューが出てくる。あとは、ネットワーク経由でパッケージをダウンロードするインストールの方法と一緒。

CDメディアを作成するよりお手軽かな。