Daily Ohkura Info

あちらやこちらで1年を振り返るのがはやりらしいので、振り返ってみる。

1月,2月
・携帯アプリ開発のバイトが大変だった。ソフトウェア開発の「下請け」というのがいかに大変な世界かを体験した。
・卒論を書いた。英語での論文なんて書けるわけないと思ったが、誰も読まないから英語じゃなくても問題ないはず（ローマ字でもばれないんじゃないか？）。

3月　
・学会デビュー。自分のやったことを言うのに、人様にお時間を取ってもらうなんて申し訳ないです。
・ブログパーツの開発に関わったのもこの頃か？
・学科の数人で箱根にいく。ysnのすばらしいセンスのせいで午前4時まで笑い転げる。
・無事卒業

4月
・バイトが新しい場所になった。自由度が高くて、負担がだいぶ軽くなった。
・5月の海外でのワークショップが通ったらしい。（一応）査読があるものとしては初。
　ぼくの英語が読めるかどうか心配だったけど世の中の人は英語に対して寛大らしい。

5月
・海外発表初体験@スコットランド。かなり緊張したけど、発表は惨事にはいたらず終了。
・↑のおまけで、イタリアの学会に遊びに行く。

6月
・ICPCのプログラミングコンテスト。予選は通過（したと知ったのは9月だけど）。

7月
・ぼーっと過ごす

8月〜10月
・アメリカ滞在。4人( or 5人)で共同生活をしていた。プライバシーないのはあれだけど、楽しかった。
・インターン。週5で働く初めての職場が英語圏というのはなんとも大変でした。面白かったけど。

11月
・プログラミングコンテスト。日本代表（？）にはなれず敗退。練習せざるものに栄光なし。

12月
・淡々と過ごす

今年初めに書いたらしい目標では、「表に出て行く年にしたい」と書かれています。去年よりは表に出ていただろうけど、「あ、あのおーくらくんですか」といわれるにはほど遠いですね（というか1歩も進んでない説）。まぁそんなもんでしょう。

最近携帯の電池が持たなくなった。30分くらいメールを書いたりインターネットにつなぐと電池がなくなってしまう。
原因はよくわからないが、アメリカに行っていた3ヶ月の間使わなかったからかもしれないし、USBケーブルで充電しているのが良くないのかもしれない。
ある日電池を取り出してみたら、電池が膨らんでいた。最初は気のせいかと思ったが、裏ぶたが閉まらない。間違いなく膨らんでいた。

爆発すると評判のSonyバッテリーのことが頭に浮かんだので、すぐに新宿のDoCoMoショップに行った。
調べてもらったところ、電池の蓄電能力はほぼゼロ。膨らむのは電極のゴミがたまる（？）かららしい。
本体に以上は全くないことも分かったので、電池を交換するしかないということになった。

年末で流通が止まっており、また使用している機種は1年ちょっと前に出た人気機種で電池の買い換え需要が急増しており、店舗には電池の在庫がないということがわかった。
年明けすぐに電池を取り寄せるか聞かれたが、電話が年明けまで使えないのはまずい。
　店員さん「入荷し次第すぐにお電話をいたしますが・・・」
　自分　　「その電話が使えないんですが・・・」
とかいうやりとりをしながら、ほかの店舗の在庫を探してくれることになった。

近くの店舗に加え、学校の近く、通学に使用する電車の沿線など10店舗以上電話をかけて調べてくれた。
話し中の店舗に何度もかけてくれたり、在庫がすぐに分からない店舗は折り返しの電話をお願いしてくれたり。
「お待たせして申し訳ございません・・・」と謝ってくれるが、むしろこっちが「お手間をおかけして申し訳ありません・・・」という感じだ。

結局30分か1時間くらいねばって、夜に秋葉原の店舗に数個入荷することを突き止めてくれ、取り置きしてくれた。
結局夜に秋葉原に行き、その日中に携帯をつかうことができるようになった。使えなかった時間は6時間くらいだ。

店員さんの対応の良さ、親切さでは他のキャリアと比べてDoCoMoはすばらしいとおもう。
携帯の料金プランや付加サービスの競争が激しいけれど、こういう表には出てこないサービス面も重要なはずだ。
表面上の数字に表れないこういったサービスもきちんと評価できるような枠組みがあるといいのに。

NLP（自然言語処理）とWebマイニングの間のようなことを研究テーマにしているので、Web上のデータをとってきて処理することは多い。
ブログのデータを集めてきて単語の出現頻度などの統計をとっているが、これらのデータはノイズが混じっていることを前提に処理している。

一方、データを処理するためのツールやライブラリ、一部のデータもWebからとってきたものを利用している。
しかし、通常これらのものにはノイズが混じっていないことを前提にして研究をしてしまう。

今回、実験の結果得られた統計値に妙なバイアスがかかっていることを発見した。デバッグに丸1日程度かかってしまった。
調べて分かった原因は、オンラインで公開されているデータの一部が欠損していたことだった。

Webから取ってきたデータを「信頼できるデータ」と「信頼できないデータ」の2種類に分けて、信頼できないデータばかり疑っている自分に驚いた。

「若者はなぜ3年でやめるのか」という流行の（？）本を読んでみた。

基本的には
・年功序列の前提が崩壊しつつある
・年寄りの給料は若者が払う
・若者は将来もらえないかも
・だったら離脱するの当たり前じゃん
という年金未払いと似た構図が会社でも起きているよという話。
（何でたったこれだけのことを書くのにあんなにページが必要なんだ？というのはおいといて。）

3年でやめる。むしろ、年功序列の組織には入らない。という話はいい。
でも、この本で語られているのは主に今若者が、今の生活のためにどうするのがベストかだ。
自分が40歳になったとき、成果主義＋年老いた人は首切りというのが広まっているとして、そのときどうしたらいいのだろう？
そのときに向けてどういう進路をとるのが正しいのだろう？
この本には、この部分のヒントが全くといっていいほどなかった気がする。

でも現状を理解するにはいい本だと思うので、読んでいない人は読んでみてもいいと思う。

数日前の毎日新聞の記事に衝撃的な話が載っていた

ヤフーやグーグルなど米国の大手検索事業者の多くは、瞬時に検索結果を提供するため、保有する大量のサーバーに世界中のホームページの内容などを蓄積し、キーワードや内容などの索引（インデックス）を付けている。日本の著作権法では、著作権のある情報を蓄積することは「複製」、索引を付けることは「編集」と解釈され、ビジネスに利用することは違法だ。事業者はサーバーを日本に置くことができず、適法としている米国などの海外に設置している。

検索サーバー：国内に設置　実現へ著作権法改正方針

まずこの報道をまとめてみると、
1. ホームページのデータを蓄積することは「複製」と解釈できる
2. インデクシングは「編集」と解釈できる
3. ビジネスへの利用が違法
4. 国内の事業者もサーバーは海外に置いている
5. 国内設置が認められないという認識を既に政府が持っている
となる。

1,2については法律は専門外の自分にはよくわからない。「ナガブロ:著作権法的には海外の検索サーバーもマズいと思うんですが。。」によればこの認識は正しいらしい。そして、同サイトによれば4のようにサーバーを海外に配置するだけでは問題は解決しないとか。

さて、ここではそもそも4番のようなことが実際に行われているのかという点について検証してみる。
検索エンジンの裏側でデータがどう保管されているのかということについてはちょっと分からない。しかし少なくとも検索エンジンのフロントエンドがどこにあるかはPingの時間を比べればだいたい予想がつくはずだ。
いくつかの検索エンジンサイトに、日本にあるサーバーとUSにあるサーバーからPingを打ってみた。

※それぞれのドメインからIPアドレスを日本で引き、そのIPアドレスに対する日米のサーバーからのPingを3回ずつ測定した中央値。

この表から、日本語の検索エンジンの少なくとも検索結果を返すフロントエンドはほとんど日本にあることが見て取れる。また、太平洋を横断するには100ms程度の時間がかかることも分かる。

YahooやGoogleはページ上に検索にかかった時間が表示される。YahooJapanの検索速度は、キャッシュにあれば0.02秒程度、キャッシュになければ0.5秒程度のようだ。Yahooにキャッシュにヒットしそうな検索クエリをwgetで投げてみたら0.16秒で返ってきた、逆にキャッシュにヒットしなさそうなものでは0.63秒。どちらもだいたい140ms程度検索以外の時間がかかっている。localhostにwgetしてみても10msかかるので、この分はHTTPのプロトコルで必要な時間と考えても、残り130msある。普通に考えれば検索結果のsnippetを生成している時間と考えられるが、もしsnippetや広告もキャッシュしておいているとすると、この時間は太平洋を横断して海の向こうの検索サーバーに問い合わせている時間とも考えられる。

結局結論は出せないが（検索結果が100ms以下で返ってくる例があればわかりやすかったのに！）、キャッシュヒット時の検索結果の時間のほとんどは何かよく分からないことに使われている。記事を読んだとき、検索サーバーが海外にあるというのはちょっと信じられなかったが、調べてみてあながち嘘ではないかもしれないと思った。

日本語をうまく扱えないプログラムは多い。海外製のソフトで日本語をうまく扱えるものは決して多くない。これは主に彼らのinternationalization(i18n)に関する知識が少ないため・・・という話はよくある。ところが、日本人でもプログラムのi18nについて知っている人は少ないような気がする。恥ずかしながら自分もほとんど知らなかった（研究で日本語データを扱っているのに！）。

最近Joel on Software（もちろん日本語版；）を読んでいて、「すべてのソフトウェア開発者が絶対確実に知っていなければならないUnicodeとキャラクタセットに関する最低限のこと（言い訳なし！）」の章を読んだ。たった数ページだけど、コードページとかUnicodeとUTF-8の違いがなんとなく分かってしまった。WindowsでUnicodeを扱うときなぜ”WideChar”という名前のものを使わないといけないのかとか、UTF-8はUnicodeなはずなのにどうしてwcharで読み込んでも正しく扱えないのか、UTF-8はUnicodeなのになぜUTF-8でエンコードされた英文は普通に読めるのか・・・。個人的に引っかかっていた部分が全て氷解した。

この本は会社でプログラム開発を担当している管理職を対象としている本で、自分には関係ない話も少なくはない。でも、知っておいて損になることはないし、むしろ知ってよかったことは多い。マネジメントの話は自分と直接関係ないようで、人間誰もが自分自身のマネジメントはしないといけないわけで、その観点からするとマネジメントの本だからといってスルーするのはまずいような気がする。（とかいいつつ、いい本だって友達に聞かなかったら自分も読んでなかったと思うけど。）

ちなみにこの記事はオンラインでも読むことができる。
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Wekaというものを使ってみた。存在は1年以上前から知っていたが、機械学習アルゴリズムのJavaによる「ライブラリ」だと思っていた。しばらくの間研究に必要なプログラムをC++またはRubyで書いていたので、Wekaに目を向けることはなかった。

いまBlog関連でやっている研究で、ある問題に文書分類アルゴリズムを使ってみようと思った。今回のテーマでは研究用プログラムをJavaで書いてみていて（書くの楽ちんだしね！）、C++のときに使っていたTinySVMや自作のNaiveBayes, AdaBoostライブラリの代わりになるものとして自然とWekaに目がいった。

Wekaをダウンロードして、ホームページに目を通すと、単なるライブラリではないことが分かる。たくさんの機械学習アルゴリズムが実装されており、それぞれのアルゴリズムは必要なパラメータを設定できるようになっている。さらに、たとえばスペース区切りの単語をfeature vectorとして扱うためのフィルタのように、一般的に学習アルゴリズムを使う際に必要な処理がプラグインのような形で用意されている。そして、これに何よりも驚いたが、これらのことが全てGUIからできるようになっている。

GUIの使い方が分かってから、目的のデータの分類精度をNaiveBayes, SVMそれぞれで10通りのデータサイズで精度と速度を見るのに1時間かからなかった。今まで使ってこなかったことが残念だ。研究用に使えるツールにはGUIがないものが多い。GUIがないというのはCUIがないよりはずっとマシだが（CUIがなければスクリプトで制御できないから）、manページで調べなくても何ができるのがぱっと見で分かるのはとてもありがたい。