Mahout in ActionのChapter2についての自分の理解をメモ。

推薦の定義

• ユーザベース
  ・ユーザとアイテムの関連に基づく推薦。
  ・嗜好の似ている人が好きそうなものを推薦する。
  ・属性は考慮しない。
  ・Mahoutで適切に表現可能

• アイテムベース
  ・ユーザとアイテムの関連に基づく推薦。
  ・好きなアイテムに似ているアイテムを推薦する。
  ・属性は考慮しない。
  ・Mahoutで適切に表現可能

• コンテンツベース
  ・アイテムの属性に基づく推薦。
  ・Mahoutはあまりサポートしない。
  ・Mahoutと組み合わせて実現可能。

初めての推薦エンジン

• ここではユーザベースの推薦アルゴリズムを使用
• MahoutのインプットデータのIDは常に数字（整数）。嗜好度は大きい値がより嗜好度が強いことを意味すればどのような値でもよい。

• CSV形式でインポートデータを用意。

• Recommenderの作成
  ・DataModel：データの保持、データへのアクセス
  ・UserSimilarity：ユーザ間の類似度
  ・UserNeighborhood：ユーザの類似グループ
  ・Recommender：上記コンポーネントを元に推薦アイテムを抽出

• 結果の分析
  ・現実はデータ量が膨大でノイズも含んでいる
  ・膨大なデータから正しい結果を素早く抽出することは重要

Recommenderの評価

• 実際のデータの一部を元にシミュレート可能
• 評価された結果と実際のデータの間での平均値の違いを計算可能
• 上記評価の値は小さいほど良い
• 上記値が0.0の場合、評価された値と本番データの差はないということ
• RecommenderEvaluatorはデータを評価用に分割し、DataModelとRecommenderを生成し、評価された値を実際のデータと比較する
• 例でevaluate()メソッドにRecommenderが渡されていないのは、メソッド内部で新たに作られたDataModelについてRecommenderを生成する必要があるため
• メソッドの呼び出し元からDataModelからRecommenderを生成するためのRecommenderBuilderを渡す必要がある。
• ここではこの章で前出の実装と同じものが生成される
• RandomUtils.useTestSeed()では毎回同じランダム値を取得する。本番コードで使ってはいけない。
• プログラム2.3の例では実行結果は1.0が返ってくるが、この値の意味は実装に寄って異なり、ここではAverageAbsoluteDefferenceRecommenderEvaluatorが使われている。
• 実行結果が異なるかもしれないが、それはデータセットの分割がランダムであり、実行の度にトレーニングセットの内容が異なることによるもの。
• root-means-square（二乗平均平方根）によるスコアリングに変更する場合は、AverageAbsoluteDifferenceRecommenderEvaluatorをRMSRecommenderEvaluatorに置き換える
• evaluate()メソッドにnullの代わりにDataModelBuilderを渡すことができ、それによってトレーニングデータからどのようにDataModelが作られるかを制御することが出来る。通常はデフォルトが良い。
• 例でevaluate()メソッドに渡されている1.0という値は入力データのどれぐらいの割合が使われるかということで、ここでは100%とという意味。

正確さと再現度の評価

• 正確さは上位の推薦結果の中の良い推薦の割合。
• 再現度は良い推薦の中の上位の推薦結果に含まれる割合。
• Mahoutはこれらの計算を極めて簡潔な方法で行うことが出来る。
• RandomUtils.useTestSeed()を使わない場合、ここではデータセットが小さいので、結果はデータセットのランダムな抽出に大きな影響を受ける。
• 推薦結果の良し悪しを分ける明確な境界が与えられていない場合、フレームワークがユーザごとに嗜好の平均に標準偏差を加算したものを使用する。

GroupLensのデータセットを評価する

• GroupLensとは実際のユーザの映画に対する評価のリサーチプロジェクトで、いくつかの種類の大きさのデータセットを提供している
• ここでは 100Kデータセットを使用 http://www.grouplens.org/node/73
• ダウンロードしたファイルを解凍した中に含まれている ua.base はタブ区切りのユーザID、アイテムID、評価、その他の追加の情報のファイル
• FileDataModelで扱うことができる。前出のintro.csvの代わりに使用
• Slope One Recommenderを使用してみる
• RecommenderBuilderでSlopeOneRecommenderを使用するようにすることで利用可能
• サンプルを実行すると非常に高速だが、Slope Oneアルゴリズムが常に高速というわけではない
• 計算の前処理に非常に時間がかかる場合がある
• この違いは実際のデータでテスト・評価することの大切さと、Mahoutを使うと比較的簡単に行えることを示している

　会社の同僚とMahout in Actionの勉強会を始めたので、Chapter1についての自分の理解をメモ。

Mahoutとは？

• インドの像使いという意味の言葉
• Apacheプロジェクトのオープンソース機械学習ライブラリ
• 主要テーマは推薦エンジン（協調フィルタリング）、集団形成（clustering）、分類（classification）
• スケーラブル
• Javaで書かれたJavaライブラリ
• Hadoopの上で動かすように作られている
• Apache Luceneのサブプロジェクトとしてスタートして2010年にトップレベルプロジェクトになった

MahoutとHadoopで大規模データに取り組む

• 機械学習技術は大規模なデータを基に使われる
• パワフルなコンピュータでさえ1台で処理するのは難しい
• Mahoutのような実装がなければ困難
• スケーラブルな分散環境はHadoopにより実現

Mahoutセットアップ

• Java6以上が必要
• IDEの使用をオススメ（Eclipse, NetBeans, IntelliJ IDEAなど）
• Mavenをインストールする
• Mahoutはまだ開発中で、執筆時のバージョンは0.5
• ダウンロードサイトからダウンロード可能
• もしくはSubversionから最新のコードを取得可能
  https://cwiki.apache.org/confluence/display/MAHOUT/Version+Control
• 取得したソースからIDEでMavenプロジェクトを作成（方法はIDEによって異なる）
• Hadoopを擬似分散モードでインストールする（本書ではVersion 0.20.2を使用）
• ちょっと違う方法で自分なりに環境を作ってみたエントリはこちら

　Google Developer Day 2011 Japanに行ってきたので会場の様子をちょっと紹介。

　基調講演やブレイクアウトセッションについては前のエントリで少し書いたのでそちらをどうぞ。

• Google Developer Day 2011 に行ってきました。
• GDD 2011 Japan のブレイクアウトセッション

　エントランスロビー。オブジェは正二十面体にGDDの開催地がマッピングされた展開図になってるらしいです。

　デベロッパーサンドボックスのコーナー。芝浦工業大学とco-meetingの説明を聞いてきました。

　NFCを使ったスタンプラリー的なもので、「NFC QUEST」。会場内のいろんなところにNFCのチェックポイントがあって、入場時に配布されたカードでタッチするようになってました。右下の写真はBar Androidの出張店舗。

　こちらはGTUGコーナー。

　Chrome Bookも展示されていました。ちょっとしか触ってないですが、普通のノートPCとすごく違うような印象は受けませんでしたね。

　さらにGoogle TVも。今度docomoから出るGalaxyも展示されてたらしいのですが、私は見てきませんでした。

　こちらはAndroid関連の展示。

　パノラマなGoogle Earth。

　メディアラボとGooglerによるパフォーマンス。メディアラボはGoogleとのコラボでWebサイトへアクセスすることによる観客参加型のセッション。Node.jsとWeb Audio APIを使った仕組みだそうです。Googlerは須藤元気のWORLD ORDERと同じダンスパフォーマンス。ダンス経験者はほとんどいなかったそうですがそうとは思えないなかなかすごいものでした。

　「あなたが書いた自慢のコードは何ですか？GDD会場に刻みつけよう！」ということで参加者が自由にコードを書き込めるボード。右は終了後に会場外で取った夜景です。

　GDD Tシャツ。洗うとすごく色落ちしますw 缶バッジは入場時に一人当たり同じものが10個ずつ配られて、他の参加者と交換してコンプリートしてくださいということでした。参加者間の交流を促すための取り組みですね。私は知らない人に話しかけるのが苦手なので集まったのはこれだけw

　こちらも全員に配布されたzeemoteのBluetooth接続のジョイスティック。Android端末でゲームをやるときに使えます。ゲーム以外にもBluez IMEというIMEアプリを入れるとキーボード入力代わりにつかえるので、プレゼンでスライド送ったりとかにも使えていい感じです。3Dメガネはクロージングで動画を見るのに使う予定だったらしいのですが、Igniteが長引いたことで割愛されてしまったそうで。。。出番ありませんでした。

　全体的な感想としては、入場時の配布物とか昼のお弁当配布とかはもうちょっとスムーズにならないかなぁという感じです。だいぶ並んで待っている時間が長かったので。。
　セッションをしっかり聞こうと思うとバッジの交換とかブースを回ったりとかっていう時間はあんまり取れないのが残念なところですね。
　あとはセッション会場でも電源が取れると良かったんですが。。

new BSDライセンスがついているものをアプリに組み込みたいなと思いましたので改めて調べてみました。
結論から言うと、

1. EULAにLicense文書をそのまま入れる
2. アプリ内にLicense文書を表示するwebViewを作る：設定やAboutなどで

の2つをするがベストな感じです。

[参考1] @takuma104さんのブログ

NatsuLion for iPhone クローン (略) から学んだこととかまとめ - @takuma104 log http://d.hatena.ne.jp/takuma104/20090329/1238329981

具体的には、

AppStore で配布する際の iPhone アプリで、New BSD License のコード等を使用する場合の適切な方法は、僕の考える限り、以下ぐらいの手法ではないかと思います。

1. EULA に License 文書をそのまま入れる
2. アプリのどこか、たとえば「設定」や「このアプリについて」とかに、License 文書を全文表示できるような仕組みを作る (webViewっぽいViewで組み入れているものも見かけますね)
3. AppStore からリンクされているサポートページが事実上ドキュメントなので、そこに License 全文記載されているページへリンクする

[参考2] 他のiPhone開発者の方々に聞いてみました

Twitterで聞いてみたところ、@azu_reさんが

@azu_re : @satoko 自分はアプリの設定あたりに"このアプリについて"みたいな感じのWebView作って、ライセンス文流し込みました
http://twitter.com/azu_re/status/132288479706095616

というtwtを下さいました。他にも実際にこういう手法を取っていらっしゃる開発者の方は何人かいらっしゃるようでした。

[参考3] Instagramアプリでの表示例

ちなみに、Instagramアプリでは、Profileタブをタップ、右上Aboutをタップ、Libraries項をタップすると下記のように表示されます：
(なぜかとても見づらい状態で表示されていますがw)

[おまけ] EULAって何？

BSDライセンス絡みメモ：EULA ってなんですか？ « 寺子屋サルでき旧館 | iPhoneアプリ開発をもっともっと楽しく！困ったらみんなで解決！
http://sarudeki.maiway.jp/forum/topic/37

Where is the iPhone app EULA displayed for the user?
http://stackoverflow.com/questions/1960338/where-is-the-iphone-app-eula-displayed-for-the-user

　Google Developer Day 2011 Japan に行ってきました。

　午前中の基調講演については前のエントリで感想等書いたので、今度は午後のブレイクアウトセッションについて少し。

「App Engine最新機能」

　今回のGDDでは自分としてはクラウド関係の情報に触れたいと思っていたので、主にクラウドトラックのセッションに参加してきました。中でもやっぱりGAEのセッション、「App Engine最新機能」を楽しみにしていました。

　セッションで使われたスライドはこちら。 　http://goo.gl/2pNfD

　サイト上のセッション紹介ではMapReduce APIについても紹介がありそうに書かれていたので期待していたのですが、残念ながらセッションでの紹介はありませんでした。
　セッション冒頭で会場にアンケートを取ったところ、GAEを使っている人は6割程度、Java版とPython版が半々、Go版は3名ほどという感じ。自分のイメージではJava版を使っている人が多いと思っていたのですが、Python版を使っている方も多いんですね。

　自分はGAEについてはかなり前にチュートリアルをやった程度で今まで足りなかった機能とか最新機能としてこれが追加されてすごく良くなったとかはまりピンと来ていないのですが、いろいろなAPIがあったり、セキュリティやパフォーマンスの改善が行われていたり、トランザクションがサポートされるようになったり（XG Transaction）と最近追加されている内容だけでも盛りだくさんの様です。
　GAEのチームでは公約はしていないものの毎月リリースをする方針の様で、どんどん改善されていっている様ですね。ただ開発する側は大変だそうですw
　自分としては最近HadoopやAWSを触る機会が多かったので、比較できるように色々調べてみたいと思っています。

　そのほかに参加したセッションとしては、

「クラウド上でイケてるゲームを構築しよう」

　つかわれた資料はこちら

　ゲーム開発をほとんどしたことがない自分としては新鮮でした。PlanNというフレームワークを紹介していて、セッション内でバグレポートを実際に投稿したりw、その場でどんどんゲームの画面を作っていってしまうところがおもしろかったですが、なんと20分ぐらいでセッション終了。。

「今までにないサイトを作る：HTML5 による最新ウェブアプリ」

　Power of Cloud + Rich Front End でWebアプリを構築していくという内容で、「とにかくユーザの参入障壁を低くすることが重要」で、ユーザがサービスを使い始めるまでに必要な手間を極力減らすべきというようなことを言っていました。この点はすごく共感できますね。
　業務でWebアプリ開発をやっていると、サービス提供側としてはいろいろな情報を取りたくなってしまいますが、やっぱりそれではユーザがなかなか使い始めてくれないので、まずは使ってもらうことを意識することが必要ですね。

行っときゃ良かったと思ったセッション

　他のセッションとかぶっていたので出なかったんですが、Chromeのデベロッパーツールのセッションには行っておけば良かったと思ってます。他の方のTweetを見ていてもかなり良かったようで、実はこの一番日々の開発にすぐに活かせる内容だったのではないかと思ってます。

DevQuizの解説

　Igniteの最後にDevQuizの解説がありました。今回のボーダーラインは100.56点。自分は100.8点だったのでやっぱりギリギリ。。危なかった～。

　1400人以上が100点以上を獲得して、出題チームの意図に反して最後のスライドパズルの問題が決戦の場になってしまったようです。スライドパズル5000問のうち4000問目以上はそこまでより一気に難易度が上がっていた様で、解けた人は解けなかった人の1000倍速いアルゴリズムを組んでいたとのことです。自分は力づくのやり方しかできなかったので足元にも及びませんね。。

　Google Developer Day 2011 Japan に行ってきました。日本では今年で5回目らしいですが、私は初参加です。

　ここではとりあえず午前中2時間の基調講演について。

　今回のGDDテーマは主に4つ。

• Android
• Chrome/HTML5
• GAE
• Google+

　基調講演だけでなく、セッションも上記4種＋TechTalkという構成になっていました。

　今回一番ホットなトピックはやはりつい先日 IceCreamSandwich がリリースされたAndroidですね。基調講演の中でも一番最初でしたし、午後のセッションの会場もAndroidのセッションは主に一番広いメインホールが割り当てられていました。
　デモでは新しい連絡先アプリにあたるものと、Android Beam, Face Unlockの紹介がありました。新しい連絡先アプリのUIは、WindowsPhoneのメトロUIに近いような印象を受けました。メトロUIは良さそうだと思っていましたが、今後UIはこちら方向へ進んでいくんでしょうかね。
　Androidはどんどん機能が追加されてますます面白いことが出来そうな気がしてきますが、開発側として気になるのはデバイスの乱立への対応なので、そのあたりのいい解決方法が見つかるとみんな幸せになれるんじゃないかと思います。

　あと力を入れている印象が強かったのはChrome/HTML5でした。標準技術であるHTML5 + クラウド + Chromeでリッチなアプリケーションという流れを加速させて行こうという印象でした。一般的にはまだChrome Web Storeからアプリをインストールして使うというのはメジャーではない気がしていますが、シェアが拡大できればおもしろくなっていきそうです。
　また、アプリの構築に使う技術だけでなく、ChromeのDeveloperToolの紹介もありました。今まではあまり深く使っていなかったんですが、これはかなり便利そうです。デモでは難読化されたJavascriptを整形して表示したり、CSSを直接編集して変更履歴の追跡やファイルの上書きというようなことをやっていました。このあたりの内容はすぐに日常の業務に生かせそうですし、相当高機能っぽいということを実感しました。午後にDeveloperToolのセッションがあったのですが他に出たいセッションとかぶっていてあきらめたら、あとでTweetをみるとかなりよさそうだったので、そちらにいけばよかったと後悔。。。DeveloperToolの詳しい使い方を調べてみようかという気にさせられました。

　個人的に今回色々情報収集したいと思っていたのはクラウド関連で、デモでは最近追加された Google Cloud SQL が紹介されました。HadoopのHiveだとHiveQLがMapReduceのジョブに変換されるので、それを意識したクエリにしないと結局遅かったりしますが、Google Cloud SQLはどうなのか気になるところです。パフォーマンスが良いのであれば普通にSQLで書けた方がやっぱり便利なので、その辺調べてみたいですね。
　GAEはAndroidなどと比べると派手さはないと思いますが、Android, Chromeなど様々なサービスの基盤となる部分で、自分としても今注目している分野なので、Googleのクラウドのことをもっと調べてみたいと思います。

　それとGoogle+。自分としては純粋に「おもしろそう」と思えるサービスで、デモでやっていたHangoutのアプリなんかはすごいなぁと思うのですが、カギはやっぱりユーザ数でしょうね。増えてきてはいるようですがまだまだ少ないですし、やはりFacebookという巨人がいるので、すでにそちらでネットワークが構築されてしまっている場合にはなかなかGoogle+に変更しようという気にはなれないと思うので、普及するとしてももう少し時間がかかるかなぁという印象です。

　そして最後にはエンジニアの価値向上のために「Three More Things」ということで3つの言葉が挙げられました。

   1  なにごともエンジニアありき
   2  百聞は一デモに如かず
   3  日本で「イケる!」と思ったら、世界のみんなも同感するかも

　うーむ、大事ですね。うちの会社は比較的エンジニアを大切にしてくれている方だと思っているのですが、もっと、いい意味でエンジニアが幅をきかせることができるようにしていきたいなぁと思います。そしてあんまり考えすぎるより実際に手を動かして示してみるというのも改めて大事だなぁと思いました。