Category Archives: Uncategorized

始めたら絶対にハマると分かってたので、これまで約２年間確信犯的に（←誤用）近づかないでいたtwitterだけど、長期で海外にいる今こそアウトプットの必要性をひしひしと感じているのではじめてみました。ブログにするまでもない、くだらないネタや日記的なものを更新していこうと思う。 http://twitter.com/mhagiwara そうしたら自分が書く内容のほとんどがブログにするまでもないものであることに気づいたので、しばらくはそっち中心に更新していくかも。たぶん中国語の話が多いです。 しかし twitter がほとんどのブロガーの執筆欲を奪ってるっていうのは本当かもなー。twitter がなかったらブログ界はもっと良記事であふれるに違いない。（だらだらと雑談 or 独り言　を書きながらそれがアウトプットになってるっていうのは確かに良いかも）

25日は名古屋大学の卒業式。博士課程の３年次は特に色々あったけど無事博士号を頂くことができました。これも研究室の先生方をはじめ、５年以上に渡る研究生活を支えて下さった全ての方々のお力添えのおかげです。色々とお世話になりました。 ３月は、引っ越しに出張ｘ２と、色々な人との出会い＋別れ（＋飲み）で、怒濤のように日々が過ぎていってしまいました。引っ越しも落ち着き、今日から１週間弱は東京で暮らしてますので関東圏のひとはよろしく！ 写真は最後に研究室のメンバーでパチリ。顔出しＮＧの人は言ってください（事後報告）

（写真：香港大学から見た高層アパート群と、ヴィクトリア・ピークからの夜景） 週末から今日にかけて、研究室で参加している 日本法令翻訳プロジェクト http://www.kl.i.is.nagoya-u.ac.jp/told/ の関係で香港大学を訪問していました。 自分は法律文に統計的自然言語処理を適用する話について研究紹介。基本的には、去年の夏に参加した、法律情報学の国際ワークショップJURISIN 2008で発表した内容と同じ。前にも書いたけど、日本の法律文というのは定型性が高いので、自然言語処理の分野で提案された統計的手法などを適用したら嬉しいよね、という話。 もう一つの研究紹介は、小川先生のBilingual KWICで、単語のアラインメントをさせながらパラレルコーパスをKWIC形式で検索できるツールである。KWICとアラインメントという、どちらもそれ単体では既に枯れた技術だが、それを組み合わせるとものすごく便利になるよ、という話の好例だと思う。 この「対応単語がわかるパラレルコーパス検索エンジン」、shimaさんのブログのエントリ： 外国語学習に役立つ、対応単語がわかるパラレルコーパス検索エンジン「LINEAR B」 http://w-it.jp/shima/2009/03/linear_b.html には、「どなたか英語<–>日本語あたりで似たようなシステムを作ってみてはいかがでしょう？」とあるが、既にここにあるよ～！ということで紹介してみました。 この「Bilingual KWIC」、今コーパスとしては法律文が入っているが、一般のパラレルコーパスを入れて英語学習者向けに公開したらウケるのは間違いない。法律関係の用語にはめっぽう強く、例えば「証券会社」と入れるとちゃんと「securities corporation」「securities company」といった訳語を推定してくれて賢い。 香港について 今回、香港に行ったのは初めてだったけど、歴史的経緯のせいで、英語、広東語、標準中国語（普通話）が街中に飛び交う、なかなかマルチリンガルな地域である。それだけで自他ともに認める自分のような「語学マニア」にはたまらない。たとえば、地下鉄のアナウンスは、広東語、普通話、英語の順に３言語で同じ内容を言うのでなんだか長ったらしくて騒がしいが、聞いてみると単に「列車とホームの隙間にご注意ください」ぐらいしか言っていなかったりする。 そのためあって、法律の言語関係は色々大変とのことで、カナダ（英語＋フランス語）と同様に中国語と英語で、最初からパラレルに法律が書かれるそうな。 英語の通用範囲はかなり広いし、標準中国語もけっこう通じるようだし（拙いフレーズを買い物するときに少し使ってみたが、こっちのほうが地元の店の人には通用するみたい）、何より書いてあるのが繁体字なので、標準中国語で使われる簡体字よりも日本人に優しいというのが良い。アジアの典型的な（カオスな）町並みと近代的なビル群が混ざったような風景は面白いし、言葉の関係もあって海外旅行初心者には良い目的地だと思う（あと料理がホントおいしい！）。そのためあって、空港まで迎えに来てくれた弟夫婦に激しくオススメしておいた。

先日、国内雑誌に投稿していた（通算）４本目のジャーナルの採録が決まった。これで学位取得のための業績の要件を（十分すぎるほど）満たしていることになり、あとは博士論文を書いて公聴会を突破すれば学位が授与される。一時はどうなることかと思ったけど、ちゃんと３年で終わってよかった（MSRにインターンに行かなければ短縮修了できたかもしれない、と後から先生に言われた。長期インターンは、そこに確実に就職するのではない限り、修士１年もしくは博士２年までに行っておくことをお勧めします）。 博士論文のタイトルは”Modeling and Selection of Context for Better Synonym Acquisition”（類義語獲得の性能向上のための文脈のモデル化と選択）で、博士論文にしてはかなり具体的なタイトルなのだけど、やってきたことは「分布類似度」を軸にして、そのための共起のモデリング、文脈の選択・拡張、機械学習の応用、というトピックを扱っていて、読むと分布類似度に関するここ１０年ぐらいの関連技術が分かるチュートリアル的内容にもなっている（と期待している）。 専攻内の下読み開始があと２週間ほどで始まるので、主査・副査の先生方に渡す仮綴じの論文をあと１週間で仕上げる必要がある。といっても、内容は（大きな声では言えないが）これまで発表した論文のつぎはぎなので、新しく手法を提案するということはない。というか、博士論文に書いてあることは、必ず外部の雑誌・学会等で採録された裏付けがないと書けないので、新しいことをしようにもできない。最近また色々と新しい手法を勉強したりで、本当は色々と補強したりやりたいことがあるのだけど。 そういえばACL-IJCNLP 2009のStudent Research WorkshopのCall For Papersがいつの間にか出てた。今年のACL 2008で１回発表しているのでもう投稿はできないけど、前の発表が好評だったのか知らないが、今回はプログラム委員をやらせてもらうことになった。要するに査読をするだけなんだけど、他はそうそうたる面々なので身の引き締まる思いである。前も書いたけど、発表に対して詳細にコメントをもらえるわ、交通費はほぼ全額出るわ（ただし小切手でｗ）、他の発表者たちと交流する機会はたくさんあるわで、非常に良いワークショップだったので、まだ学生のひとは特権を利用してどんどん発表してみると良いと思う。

日頃Windowsを使っていると、「なんでこのショートカットキーはこんなに不便なんだろう」「なんでもっと簡単にこの一連の操作ができないんだろう」ということが頻繁にある。例えば自分がMacに移行して感動したことの一つは「Cmd+Q」でアプリを終了したり「Cmd+W」でウインドウを閉じたりするのが簡単に、しかもアプリ間で統一性を持ってできることだった。誰が「Alt+F4」なんて指がつりそうなショートカットを頻繁に入力しなければいけないのか。 なので、Windowsで、「キーストロークやマウスクリックなどのイベントやメッセージを全部キャプチャ（フック）して、それに応じて自分で好きなイベントやメッセージを割り当てられるような、願わくばフックを何かの簡易言語で書けるようなカスタマイズツールがあったらなぁ」と悶々と考えてて半分自分で作ろうかとも考えてたのだけど、 まさにそういうツールが既にあったのを発見。 http://www.autohotkey.com/ AutoHotkey – Free Mouse and Keyboard Macro Program with Hotkeys and AutoText 細かい説明、使い方、サンプルなどは全部この AutoHotkeyを流行らせるページ http://lukewarm.s101.xrea.com/ に書いてあるので割愛。基本的には、「a::b」というペアをずらずらと並べ、「a」キーが押されたときに「b」という処理を行うというスクリプトを書く。この「b」という処理のところに独自言語で実に色んな処理が書ける。例えば、自分が今愛用しているスクリプト片は例えば #f:: Process,Exist,firefox.exe if ErrorLevel0 WinActivate,ahk_pid %ErrorLevel% else Run,C:\Program Files\Mozilla Firefox\firefox.exe こういうもので、「Win+F」が押された時に、Firefoxが既に起動してればそのウインドウにフォーカスを合わせ、起動してなければ起動するというもの。これでたくさんウインドウを開いているときにイチイチ「Alt+Tab」で目標のウインドウを探さなくて済むし、起動していないときも一瞬で開ける（もちろん、これまでもLaunchyを使ってたので大して起動の手間はかからないわけだけど）。自分はこのスクリプト片を他にもファイラやエディタなど頻繁に使うアプリにも書いてて、そのおかげで使い始めて３日ほど経ったけど「Alt+Tab」を使う頻度が劇的に減ってしまってとても快適。 ついでに「Win+Q」をこれまでの「Alt+F4」の代わりに使えるようにしたので、アプリを終了する（正確に言うと、「ウインドウを閉じる」だけど、Windowsではこの２つはほぼ同義）ときもMacOS Xのノリでできる。ちなみに、このAutoHotKeyを使わなくても、ウインドウを閉じるのは「Alt+Space」でコンテキストメニューを出してから「C」を押せば良い。この一連のストロークはキーどうしが近いので慣れれば一瞬でできるようになってとても便利なのだけど、これまでリアルで知ってる人に出会ったことがない。逆に、情報系の学生なのに「Alt+Tab」を知らない人は何人か出会ったことがある。 欲を言えば、このAutoHotKeyで使われているスクリプト言語があまり好きになれない。自分がまだ仕様の全貌を知らないせいかもしれないけど、バージョンアップと共に言語仕様を継ぎ足していったようなお世辞にも美しいとは言えない文法＋仕様で、これを中で全部場合分けしてパースしているのかと思うとご苦労様という感じ。なので、このスクリプト部分をもっと身近なPerl、Python、Ruby、JavaScriptのサブセットで綺麗に書けるツールがあったらもっとヒットすると思う。誰か（変態な人）がAutoHotKey上で動くLLのインタプリタを書けば良いのだけど、それならベースのエンジンから作り直したほうが早い。できる限りプログラム初心者にも分かるようにしたかったのだろうけど、それならいっそのことS式で書かせてくれたほうが自分にはやりやすかったな。 この手のハック、これまでにも同じことを思い立ってPowerProを使っていた時期があったのだけど、全部GUIベース（＋ヘンテコなスクリプト）で設定するのでうんざりしていた。あと、GUIベースの設定は違うマシン間での共有が面倒くさいが、AutoHotKeyみたいにスクリプトで全部見えればそのファイルをコピーしたりするだけで良いので精神健康上も良いとおもう。 ちなみにこのAutoHotKey、Windows上の入力イベント（キーボード、マウス、ジョイスティック）を全てキャプチャできるので、少しスクリプトを書くだけでそのままキーロガーが作れる。というかもう作った。色々と探してみたのだけど、Windows上で使い勝手が良くフリーのキーロガーというのはなかなか見つからない（そりゃそうだ、誰が必要とするのだろう。）このキーロガーは前に キーロガーを使って集中力を「監視」する … 集中力アップのためのツール案（記録編） http://blog.lilyx.net/2007/10/21/concentration-by-keylogger/ … Continue reading →

先週は熱海で開かれた NLP若手の会(YANS)の第３回シンポジウムに行ってきた。NLP若手の会は「若手」とは言うものの妙に発表のレベルが高くて、第１回目に名古屋大で開かれたときから毎年楽しみにさせてもらってる。 今回の発表内容は夏のMicrosoft Researchのインターンで取り組んだプロジェクトの紹介。EMNLPで発表することができないのでここで一度お披露目しておく意味は大きい。MSRにインターンに行くとこんなことができますよということを知ってもらい、一人でも多くの学生さんに興味を持ってもらえれば嬉しい。 タスクと手法がとっつきやすい内容であるおかげか、とても多くの方に聞きに来ていただいて嬉しい反面けっこう大変だった・・・。コメントやフィードバックも数え切れないくらいたくさんいただいたけど、特にNAISTの小町さんから、インターン中に色々と悩んだ点にかなり近い的確なコメントをいくつかもらってさすがという感じだった。 話を詰め込みすぎて１ラウンド（ポスターの説明から始めて、一通り質問が終わって次のオーディエンスのグループに移るまで）が長くなってしまったので、詳細はばっさり切り捨てて話を短くして回転率を上げればもっと多くの人にさわりだけでも聞いてもらえたかなぁとちょっと後悔。詳細部分はポスターに書かず、追加資料を紙で用意していた発表者の方とかもいて、需要に応じて詳細部分は臨機応変に小出しにしていったほうがよかった。 ポスター発表の本質って（口頭発表もそうだけど）、聴衆に 「分かった気にさせて」「元原稿を読みたくさせる」 ことができればＯＫだと思う。手法の詳細は何とでもなるので今度からもうちょい気をつけよう。 あと、ポスター発表やる側になって痛感したのだけど、発表者が手法をどんどん説明している時にも、適切なタイミングで質問や確認など「合いの手」を聴衆から入れてもらうとすごく話しやすくなる。この「適切な」タイミングというのが意外と難しいのだけど、原稿で言うと節のまとまりの終わりぐらいのタイミングかな。 あと、聴衆側で、説明が終わって質問がひととおり出終えた後もえんえんと発表者に対して（マニアックな）質問や議論を吹っ掛け続けるのは次の聴衆グループに迷惑なのでやめた方がいいと思う。どうしても一言二言言いたければセッション終わった後に発表者を捕まえてやるべき、と自戒を込めて書いときます。 発表はけっこうイッパイイッパイだったにもかかわらず、おかげさまで最後には奨励賞をいただくことができた。外の学会で賞らしきものをいただくのは初めてなので素直に嬉しい。大学の研究室でやった内容でないのがちょっと微妙だけど、インターンの宣伝？という意味では効果あったのかも。３ヶ月あれだけ集中して取り組めたおかげの成果なので、やっぱりMSRインターン激オススメです。 現段階で公式ページにポスターのPDFがまだ上がってないようなので一応ここに置いておきますね。 とりあえずブログを定期的に更新する習慣をつけたいものだけど何とかならないものかな・・・。

先日、論文の査読が返ってきたので、その回答書を書く作業をちまちまとやっていました。初めて回答書を書くときって、内容的なことは良いとして、全体的にどのようなフォーマットで、どのような文体で書くかっていうのがよく分かららずに困惑するものですよね。こればっかりは、研究室内で先輩→後輩もしくは教官→学生というようにノウハウが語り継がれているのでしょうか。(自分も、最初はフォーマットおよび文体含めて先生にチェックしてもらってました) もちろん、分野や論文誌によって慣例が大きく違って難しんでしょうが、ググっても、ふつうのビジネス文書みたいにテンプレートすら出てこないです。もしこの論文が通ったら骨格の部分だけ公開してみようかな。 おまけ： Addressing Reviewer Comments http://www.phdcomics.com/comics/archive.php?comicid=581 「困った査読コメントへの回答のガイドライン」から拙訳。 「 査読者のコメント： 筆者の提案した手法(装置、パラダイム)には、明確な誤りがあります。 良くない回答： はい、知っています。それでも何とかして論文にできると思っていまいた。すみません。 良い回答： 興味深いご指摘ありがとうございます。しかしながら、本研究の焦点は性能で はなく予備的な調査であり、有効性の検証については本論文の貢献に対して決 定的な重要性を持つとは言えません。 」 以前、マレーシア人の友人に教えてもらったマンガ、PHD (Piled Higher & Deeper)に今回の話にドンピシャなネタがあったのでネタで紹介しました。このマンガ、アメリカの大学院生の日常を描いたもので、作者 Jorge Cham はスタンフォードのOBらしい。大学院生の日常なんて、どこの国でも大して違いは無い無いようで、読んでると「あるあ・・・あるあるｗ」ってウケること間違い無しです。日本ではあまり知られていないようだけど（これまで知ってる人に出会ったことがない）、それは読者層が狭すぎるからなんでしょうか。

これまで約1年間、Macをメインに使い続けてきた自分ですが、さすがにMSRにインターン行ってまで Mac を使いつづけるほど空気読めなくはないｗので、しばらくの間、メインでWindows Vistaを使う生活に逆スイッチしてみます。実はMacBook ProのHDDを増設したのもこの目的が主だったりします。パーティション半分ずつ切っても約150GBずつ容量があるのでひろびろです。 といっても、１年ぶりのWindowsなので、結局、研究環境が構築できずに週末が終わってしまったので、しばらくは Parallels の Coherence モードで凌ごう。 あと、MSRではC#使って研究進めるっぽい話を聞いたので、久しぶりにC#の復習も行く前にしておこうとVisual Studioもインストール。C#は2年前まで研究でバリバリ使ってた言語で、実はRubyの次に好きだったりします。今ではもうバージョン3.0。早いなぁ・・・。 今回の目的のためにAmazonでポチしたソフト＋本： Amazon.co.jp： Microsoft Windows Vista Business 通常版: ソフトウェア http://www.amazon.co.jp/dp/B000JQFUFU/ Amazon.co.jp： Visual Studio 2008 Professional Edition アカデミック: ソフトウェア http://www.amazon.co.jp/dp/B0011410PI/ Amazon.co.jp： Programming C# 3.0 (Programming): 洋書: Jesse Liberty,Donald Xie http://www.amazon.co.jp/dp/0596527438/ … Continue reading →

愛用しているMacBook ProのHDD(120GB)の空き容量がさすがに少なくなってきたので、先週から少しずつ情報収集をしつつ、週末ということでえいやと交換しました。 手順はまとめるとこんな感じ 1. 旧HDDを MacBook からとりはずして、新HDDを装着 2. 旧HDDを 2.5インチ HDDケースに入れ、USB接続してそこからブート 3. 旧HDDの内容を新HDDにコピー 購入した新HDDはこれ。320GB。 http://kakaku.com/item/05366010527/ 旧HDDを入れるのに使用したケースはこれ。 http://www.ark-pc.co.jp/item/code/15400174 HDDを交換する手順は、このあたりが参考になります。 http://mac.ascii24.com/mac/review/portable/2006/03/15/661126-000.html http://somethingtaizo.blog111.fc2.com/blog-entry-45.html http://www.dcc-jpl.com/diary/2007/07/01/macbookpro17hdd/ 英語でよければ、ここが一番わかりやすかったです。他のMacや、他のパーツについてもぜんぶ説明があって他の場面でも重宝しそう。 http://www.ifixit.com/Guide/Mac/MacBook-Pro/Hard-Drive 旧HDD → 新HDDのコピーに使用したソフトはこれ。 http://www.bombich.com/software/ccc.html 以下、上記のサイトに書いてないことでハマったことや注意点のメモです。 – 一部のねじを外すのにトルクスT6という特殊な形状のドライバーが必要。ホームセンターに売ってた。最初は、家にあった細い六角レンチ(ベースの弦高を調整するのに使ってたもの)で代用していたら、途中でねじ山をつぶしてしまったのでオススメしません。どうしてもトルクスT6が入手できない場合の代用手段。 – 上に紹介した記事のひとつにも書いてありますが、本体カバーを外すときに力が必要。本体全部(トラックパッド前)に、カバーが挟んである箇所があるのでこれを力ずくで外す。バキッって音がしますが割れてないのでご安心を。 – 本体とカバーをつないでいるコネクタは外す必要なし。そのままつっかえ棒でもしてカバーを開けておけばＯＫ。なぜか上の記事では全て外すこと、って書いてある・・・。 – カバーを元にもどした後、バッテリーの内側に、手前方向に向かって水平についている２本のネジ（言葉で書くの大変だｗ）をきつくしめすぎると、なぜかMacBookを折りたたんだとき、開かなくなる（ディスプレイ部分のラッチが外れずに持ち上がらなくなる）不具合が発生しました。ゆるーく締めておきましょう。 – CCCで完全にHDDのクローンを作って、アプリ、データ等々交換前と全く同じ状態なのに、なぜかSpotlight「だけ」がインデックスを作り始める・・・。自分はランチャとしてSpotlightを使ってるので１時間ぐらいお茶でも飲んで待ってました。

最近、某案件でJavaScriptをガリガリと書く必要があって、これまでprototype.jsを使っていたのを改め、今さらながらライブラリとしてjQueryを使っています。 これはまた良いライブラリですね。 一言で言うと、「汚いけど書いてて気持ちいい」。略して「キタナ気持ちイイ」JavaScriptライブラリです。 例えば、id=elemの要素の前にある要素の幅とフォントを設定して表示してから内容を設定して選択・・・というような一連の処理を、以下のようにドット演算子でドンドン繋げて書けるのがすばらしい。 $(“#elem’).prev().width(100).css({fontSize: “12px”}).show().val(“hoge”).select(); あとは、例えば要素をグリグリ移動したりする系のWebアプリだと、自分でこんな拡張↓を書いてやると さらに幸せになります。これは、要素のY座標を一発で取得（もしくは設定）してやる関数です。 jQuery.prototype.top = function(val) { if (val == undefined) return this.offset().top; else return this.css(“top”, val + “px”); }; しかし、このjQueryの「キタナ気持ちイイ」感じ、どこかで見たことあると思ったら、まさしくRubyの「キタナ気持ちよさ」じゃないですか。eachとかそもそも「$」とか、人間の理解上自然な範囲でメソッドを濫用（オーバーロード）してるところとか、上のように処理の順にドット演算子でずらずらつなげられるところとかそのまんま。 前にまつもとゆきひろさんが講演で、言語の設計において多くの人が「シンプルにしすぎてしまう」という過ちを犯す、ということを話しておられました。プログラミング言語において、シンプルさイコール書きやすさ、ではないことはRubyの非シンプルさが証明しています。 考えてみればWebサービスなんかもそうですね。自分らエンジニアって、ついつい設計を美しくシンプルにしてしまう傾向があるのだけれども、それが必ずユーザーの気持ちよさに繋がっているかどうかを常に自問自答する必要がありますね。