週末、金曜・土曜にかけて行って発表させてもらいました。

NLP若手の会 第2回シンポジウム
http://sslab.nuee.nagoya-u.ac.jp/yans/

このシンポジウム自体は去年から開催されてて、第１回は名古屋大学で行われたのでその時から参加させてもらっているわけですが。今年は東大で行われました。

「若手の会」ということもあって、助教の先生以下、修士以上、ぐらいの研究者が集まってこんなことやってます、とかこんなことやりたいです、というのを発表しあう会です。でも、「若手」とはいいながらも、業界でほぼ第一線で活躍されてる研究者の方々が集まっているので、なにせ発表のレベルが高い高い。言語処理学会年次大会よりも平均レベルはけっこう高いんじゃないかな。

ということで、自分の発表に対しても色々有益なコメントを頂けたり、他の人の面白い話も聞けたりして実に有意義な会でした。

今回も、色々とレベルの高い研究を聞く事ができたんですが、実際「これはすごい」って思う研究って、(1)問題がシンプル (2)解法がシンプル (3)結果が明らか (4)それに誰も気づかなかった、っていうのが多い気がします。そういう研究を目にすると「なんだ、そんなことか。それなら自分にでもできるよ」って思った気になりますが、それなら自分がやってみろ、思いついてみろ、と。そういう類の研究。今回最優秀賞を受賞したO野原さんの発表を聞いてて思った。

改めて考えてみると、こういうのってWebサービスの開発にも言えそうですね。
「なんだぁ、そんなん俺にだって作れたのに」って言う前に、自問自答してみることにします。

「それならなぜあなたは作らなかったのですか？」

後、色々収穫：

- 飲み会でO野原さんにPFIのこととか色々と聞く。ちなみに回りに座ってた人の中で3人がG社インターン経験者で3人がG社内定者だった(重複あり。自分含む)。今年の東大院卒のCS 20人のうち実に7人がG社に行ってしまう、とのこと。ここまで浸食されてくると余計行く気が失せてしまうんだけど．．．G社。

- NAISTのK町さんとけっこう久しぶりにお話。Microsoft Researchのインターンのこととかうかがう。やっぱり就活とかインターンの情報は実際行った人に聞くに限る。ちなみに今度IJCNLPで行くインドのハイデラバードは色々と危ないらしい。なんか危険な犬が道をうろついてたり、既に今年は2回爆弾テロがあったらしい。なんでも治安が悪すぎなので基本ホテルにこもりっきり、だとか。

- 午前中のセッションに寝坊したので、S水さんに個人的にプレゼンしてもらったりして、素直に感動。C++のテンプレートにあんな使い方があったとは。機械学習も色々勉強しないと。

LinkedInに登録してから数ヶ月。先日、ふいにInboxにメールが届いていました。なんだろう、と見てみると、某大手検索エンジン会社の人事の人でした。っていうかこう書いた時点でG.Y.M.のどれかなのはバレバレですね。さらに、過去にインターン行った会社からこんなメール来るわけないから必然的にあそこかあそこなわけです。

「○○からこんにちは」（○○は会社名）みたいなタイトルで、本文は、要するにこういうもの(もちろん原文は英語)：

「
こんなプロジェクトがあって、こんな人材が欲しいんです。
あなたのプロフィール見せてもらいました。この可能性に興味はありませんか？
それか、他に興味ありそうな人知りませんか？
」

LinkedInの中ってこういうメールが飛び交ってるわけなんですね。正直メールが来たのもちょっとびっくりなんですが、LinkedInに標準で付いている返信機能にも、これまたやられました。とりあえず返信を書くわけですが、こういうメッセージを受け取ってどう思ってるかを、相手に一発で伝える機能があるんです。

えっと、再度返信はできないみたいなので記憶で書きますが、この提案はいかがですか？みたいなボタンが出てきて、「適切である」「どちらともいえない」「適切だが今はタイミングが悪い」「不適切である」のような、よく使いそうな選択肢が出てきて、それをクリックするだけでレスポンスできるというわけ。

この機能、Eメールにもあったらいいと思うんですよね。よく、相手から返信が来ないと、読んでないのか、読んでもらえたけど無視されてるのか、とか不安になるときがあるので、とりあえず「了解」「読みました」だけでもワンクリックで相手に伝えられたら便利だなぁと思うんです。わざわざ「了解しました。」だけのメールを送るのも面倒ですし。

さて、そんな感じで人事の人とやりとりが続いているわけです。メールアカウント教えて、プロジェクトの詳細とかインターンの可能性とかを相談してるわけです。現在進行形なので詳しいことは機会があれば追って書きますが、とりあえず今回のやりとりで得た教訓をまとめときますね。　

• LinkedInのプロフィールはしっかりと書いておく。（プロフィール完成度、っていうパーセンテージが出るのでわかりやすい）
• LinkedInの3rdコネクションもないがしろにしない。（人事の人はどんなルートで来るか分からない）
• Resumeはしっかり書いておくべし(当然)。相手の会社に合わせて項目を付け足してみよう。
• リファレンス(指導教官や上司に対する照会)はすぐにもらえるようにしておく。必要ならテンプレート化。

ちなみにオファーだけど、インターンぐらいには行ってみたいかも。ただ就職はどうかな．．．。アメリカの本社に直で就職できれば良いのだけど。その辺も含めておいおい聞いてみよう。

以前に、論文提出前の実験ラッシュのときに、Amazon EC2の手を借りて難を逃れた（この場合、「難」とは、大学の大規模計算機センターを使うはめになり、色々面倒な事務手続きやら学内政治やらに巻き込まれることを指します）という記事を書きましたが、ちょっと続報。

ハマった点

イメージを起動したら、まずはdfでディスクの容量確認をまっさきにやりましょう。

ここギコ！: Amazon EC2でイメージを作れるのは1.5GB分のシステム領域だけ
http://kokogiko.net/m/archives/001786.html

にも書いてありますが、homeに割り当てられる容量が予想外に少なかったので、色々計算データを置いておいたらすぐにいっぱいになってしまった点にまずハマりました。

大きいデータは、/mntにマウントしてある/dev/sda2に置いておいたほうが吉です。そして無くなったら困る大きなデータは、Amazon S3のほうに転送しておくか、rsyncかなんかで他のサーバーもしくは手元にバックアップしておくべきですね。

近況

そして最近、また計算機パワーが必要になったので再度Amazon EC2をガリガリ動かしてるわけですが．．．、なぜか前より遅くなってる。CPU稼働率が100%にならずに、50%ぐらいで頭打ちになります。変なたとえだけど、まるで「コアが半分になった」ような遅さです。

EC2側で物理サーバーにホストを詰め過ぎなのか、それとも自分のゲストのほうの設定が悪いのか、ゆっくり調査している時間がないのでとりあえずスルーですが、ちょっと心配です。

携帯で長電話してると突然のビープ音。画面を見ると「あ、ごめん電池ない！あ〜」っていうことが頻繁にあります。こういうときは、切れる10秒前じゃなくてせめて1分前ぐらいにさりげなく知らせてくれれば、それまでに何か対策とれるもの、と思うんです。電池残量の予測ってむずかしいのかな？携帯メーカーさんは何とかしてください。

友達とかなら「あ〜あ切れちゃった〜」で済むのに、相手があまり親しくない人だったり、すんごい大事な用件しゃべってたり、恋人と喧嘩中だったりすると．．．、その気まずさは誰もが経験したことある、はず。

そういう時に気まずさを軽減してくれる、かどうかはわかりませんが、こういう場面にぴったりな略語が。要するに、「ごめん、NBL！」と叫べばいいわけです。ktkr!

POLAR BEAR BLOG: ごめん、NBL！
http://akihitok.typepad.jp/blog/2007/09/nbl_9fa2.html

WWWの世界に限らず、略語ってもんはほんとに覚えても覚えても出て来るものですね。

最近では開発系MLの打ち合わせにて「XHR」って突然出てきてぶったまげたことが。これ、XmlHttpRequestの略語だそうで、これを知らないでAjaxアプリのUI作ってた自分はモグリと言われても仕方が無いかも。略さずに言うといつも噛んじゃうので、今度さりげなく使ってみようかな。

そういえばIMのチャットではじめて「AFK」って言われたときもわからなかった。もちろん「KY」も数ヶ月前に友達に教えられて知ったぐらいで、もちろんネイティブでは使えません。日々精進です。

ちなみに、論文とかでよく使う略語はお手の物なのになぁ。q.e.d., c.a., i.e., e.g., w.r.t, a.k.a, i.i.d. et al.とか。たまに使いすぎて添削の時に削られるぐらい。

ということでエントリにも略語を色々ちりばめてみたんだけど、なかなか難しいです。まぁたまにはこういうgdgdなエントリでも、ということでFA。

読んだ論文を（読まない論文も？）管理しておく良い文書管理ツールが無いものかと悩んでいたわけですが、そんな悩みを打ち明けたところ、soさんからこんなツール教えてもらいました。KIT - Keep IT Togetherというものですが、これが個人的にクリーンヒットでした。

Reinvented Software - KIT - Keep Your Stuff in One Place, Find It Again Instantly
http://reinventedsoftware.com/kit/

できることは、いろんな種類の文書（テキスト，PDF，画像，サウンド，ブックマーク）をどんどん登録していって、グループやタグやカテゴリやらで管理できるというシンプルなもの。特に論文管理に特化しているわけでも無いのですが、機能が過不足なくちょうどいい感じで、自分の求めていたものにまさにぴったりな感じなのです。

特にグループによる分類が秀逸で、一つの文書を複数のグループに登録できます。なのである論文が「トピックA」というグループと「あとで読む」というグループと「なんとか学会」というグループに登録されてる、という状態も可能。まぁタグでも良いのだけど、概念的にグループの方が安心感があるような．．気がする。もちろんタグも付けられます。

昔は、論文のPDFをトピック分けしたフォルダにそのまま放り込んで整理してたりもしたんですけど、結局このフォルダ分けの分類ってすぐに破綻してしまうんですよね。論文って，複数のトピックにまたがるものが多かったり、分類が難しかったりするものだから。

後、良い点としては、検索機能がこれまたスマートな感じ。画面下部にプレビュー機能がついているので、検索キーワード入力、そのままインクリメンタル検索、メインリストに移動、プレビュー見ながら開く、という流れが非常にスマートにできます。この間の操作も全てキーボードで可能なので「あの論文どこだっけな」から「開けたー」までが3秒ぐらいでできる。PDF本文に対する検索ぐらいならSpotlightでも可能だけど、検索対象の指定ができない（できないこともないけどやりにくい？）のとファイル名しか出ないのでKITに軍配が上がると思います。

ちょっと残念なところは、有料なところ(でもアカデミック版はやすい)と日本語や複合語(２語以上の専門用語)の検索が弱いこと、それと文書登録時にちょくちょく落ちるところか。でもそれを上回ってのメリットがあるので今後も愛用していきたいと思います。

soさんには他にも色々ツールを教えてもらったのでまた時間を見つけて試していこう。リアルでこういう技術情報交換できる同志は貴重です。感謝感謝。

余談。

ちょっと前に、研究室内での「論文共有システム」なるものを一回提案したんだけど結局お流れになっちゃた。ようするにローカルのブックマークシステムなんだけど、authority度とかコメント機能があって、先生とか先輩がブックマークしたものほどauthority度が高い，みたいな。

複数人で共同研究する場合かなり便利だと思うのだけどどこかやってる人いないんでしょうか。それともWikiで事足りるとか？実は研究室の情報共有って、依然として1.0的なところがあったりするもんですよね。意外と。

あるメールアカウントに届くメールを定期的に監視して、届いたメールに対して何かアクションしたい、というのはよくある要望ですね。Rubyでこれをやる必要が生じたので調べつつ、兼自分用メモです。

Rubyの場合、受信はNet::POP3クラスで一発です。リファレンスに丁寧なサンプルが載っているので困らないはず。

Rubyリファレンスマニュアル - net/pop
http://www.ruby-lang.org/ja/man/index.cgi?cmd=view;name=net%2Fpop

問題はその後。メールというのはそもそもテキストの固まりで、それを解析してヘッダー情報を取り出したり、本文を取り出したり、添付ファイルを分けたりしなければいけません。実はこれを全部自前でやろうとするともの凄く大変。なにせmultipartやらMIMEやら考えなきゃいけないことがたくさんあるし、色々なパターンのメールに全て対応していたらとても間に合いません(RFCを自分しっかり理解したい、というドMな要求があるなら別ですが．．．)。

ということでRubyの場合は

TMail
http://i.loveruby.net/ja/projects/tmail/

というメール解析ライブラリを使うと楽です。Debianの場合apt-getでlibtmail-rubyパッケージをインストールして終了。その他のOSの場合も上記からダウンロードしてきて

ruby setup.rb config
ruby setup.rb setup
(su) ruby setup.rb install

でインストールが完了します。こうすると、Mail.parseで一発で解析、変換してくれます。たとえば添付ファイルを取り出すならmail.parts[1].body, それをBase64.decode64でデコードすればそのままファイルに保存できます。こりゃ便利。

ということで、このTMailライブラリで全く不自由を感じないので、今後も愛用していきたいと思います。

おまけに。

上記TMailページの

インターネットメールの基礎
http://i.loveruby.net/ja/projects/tmail/doc/basics.html

というところを読むと面白いです。メールというシステムがいかにバッドノウハウの固まりかがわかります。TMailライブラリのソースコードは、なんと数千行（！）あるそうです。Rubyなのに。

まるでインターネットの負の仕様が積み重なってできているかのよう。上のページにも「メールは現在あるなかではほとんど最古参の古いシステムですから、特有の問題が死ぬほどあります。」とあります。

ふと思ったのが、今現代、もしも「インターネットを全て設計し直せる」としたら、少なくともアプリケーション層では様子は一変するだろうなぁ、ということです。自分はそっちの専門家ではないので何とも言えないのですが、少なくとも全てのプロトコルがXMLベースになるのは確実だと思いますね。ていうか、少なくともメールがXMLベースになってくれればどんなに楽でしょう。