chrome extension で JQUERY.I18N.PROPERTIES を利用する方法

chrome extension で国際化対応をする際は Internationalization (i18n) - Google Chrome Extensions を利用すると思います。ただし、 chrome の i18n は chrome(ブラウザ) の locale を参照するため、 chrome extension 単位で言語を切り替えることが出来ません。そのような場合は JQUERY.I18N.PROPERTIES を利用することで、chrome extension 単位で言語を指定することができます。

chrome extension で JQUERY.I18N.PROPERTIES を利用する方法ですが、初期化時の path を chrome.extension.getURL 関数経由で取得するようにします。こうすることで chrome extension 内の properties ファイルを利用することができます。

jQuery.i18n.properties({
    name : 'Messages',
    path : chrome.extension.getURL('bundle/'),
    mode : 'map',
    language : 'ja'
});

前述の指定だと、 chrome extension のベースディレクトリ直下の bundle ディレクトリ内にある Message_ja.properties がロードされることになります。実際に渡されるURLは以下みたいな感じになります。

chrome-extension://kobghppoominfenkoajjmdpcehnhichc/bundle/Messages_ja.properties

jQuery.i18n.properties の内部では properties ファイルの取得処理を loadAndParseFile 関数内で ajax 関数を利用して行なっているのですが、 chrome extension 内のリソースも普通に取得できるみたいです。


仕事で調査したことをブログにいつも書こうといいつつ書けていなかったので、まずはこんな感じでちょこちょこ書こうかと思います。

Hadoop MapReduce デザインパターン4章〜7章

Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理

Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理

Hadoop MapReduce デザインパターン1章〜3章 - n-3104の日記の後編です。

4章　テキスト抽出のための転置インデックスの生成

5章　グラフのアルゴリズム

  • MapReduceによるグラフの並列幅優先探索とPageRankについて書かれています。
    • グラフです。Hadoopやるならグラフは必須と聞いて、ちょっと前から少しずつ勉強してましたが、少しは理解できるようになった気がします。
    • グラフの探索の基本的なところについてはAlgorithms with Python / 集合, グラフ, 経路の探索で私は勉強しました。ちなみに、このページで勉強する前に子象本を読み終えていたりするのですが、まぁ理解していなかったということですね(^_^;)
  • まずは並列幅優先探索ですが、こちらについてはLarge-Scale Graph Processing〜Introduction〜(完全版)を見るといいと思います。実際にMapReduceによってどのようにデータが処理されているか図で説明されていてとても分かりやすいです。
  • PageRankについてはもうちょっと数学力？がついてからリトライしようと思います。概要は理解できましたが、すっきりしない感じでした(^_^;)

6章　テキスト処理のためのEMアルゴリズム

  • 期待値最大化法（EM）アルゴリズムとMapReduceへの適用について書かれています。
  • 撃沈です＼(^o^)／ 色々勉強してから出直します。
    • とりあえず文字だけ追えば雰囲気はつかめました。
    • WEB+DB PRESS Vol.64の特集3の「作って学ぶ日本語入力」も一緒に読むといいかもしれません。ビタビアルゴリズムも紹介されています。

7章　未来に向って

後半まとめ

書いてよかったです。最初に読んだ時は5章はあまり理解できていなかったのですが、今回改めて読んだり調べたりしたお陰で並列幅優先探索について理解できました。

個人的にHadoopが好きなのは、ちゃんとアルゴリズムを扱っている感じがする所です（他にもトレードオフを常に意識させられる点とかミドルウェアっぽい所とか色々ありますけれど）。普段はif文と文字列操作が大半で、せいぜい再帰処理を書くぐらいなので（モデリングやら実装パターンやら色々ありますが）。もちろん、アルゴリズムを使う仕事もあると思うのですが、自分自身にそういう能力がないこともあり、縁遠いなーと思っていた所でHadoopに出会い、とても刺激的で楽しいです。

ちなみに、Hadoopそのものよりも大規模データ処理とか分散データ処理とかそっちに興味があって、その接点としてHadoopがあると言ったほうが適切だったりします。Hadoop自体も細かな部分は変わっていきますし、10年とかのスパンで見れば残っているか分かりませんし。

いずれにしても、こんなにわくわくしながら読んだ本は久しぶりでした。筆者および翻訳者に感謝です。ありがとうございました！

2011年7月-9月振り返り

8月頭、9月頭がちょうど忙しく、気がつけば前回の振り返りから3ヶ月経ってましたorz 特に8月後半から9月前半はプロジェクトの立ちあげ、DevQuiz、Hiveの勉強会の準備が重なり、マジで精神と時の部屋に入りたい気持ちになりました。

Keep

  • Hadoopウォッチ
    • Hadoop Conference Japan 2011 Fallはとても楽しかったです(^^)
  • Feedの即日消化
    • 一時期未読が300超えててどうしたものかと思っていたが、なんとか解消できた。
  • 買った本はとりあえずざっくり全ページ眺めてみる。
    • 雰囲気はつかめるけど、記憶には残らないので意味があるのか微妙。。
  • 筋トレ
  • 毎日5分でいいので勉強する。ちなみに、今やっているのは以下の3つ。
    • 英語
    • 数学
    • デザイン

Problem

  • 7月ぐらいの案件で、お客様の期待をコントロールするという考えなしに仕事をして、結果的に不要な残業をすることになった。
    • お客様的には成果物が多くてよかったのだけれども、自社的にはコストオーバーになるし、自分自身も大変だった。
      • お客様にとっても金額と成果物のバランスが合っていないのは、その瞬間はよくても、長期的には関係を維持できなくなるのでよくない事例だと思う。
  • 技術メモをブログに書こうといって、ずっと書けていない。

Try

つぶやき

近況報告

ここ1ヶ月半ほどは1週間単位のイテレーションでお客様のところにアプリケーションを持って行き、フィードバックをもらい、翌週機能追加するということを繰り返してました。たぶん、世に言うアジャイルっぽい開発をしていたのだと思います。

お客様と一緒に開発できるのはとても楽しいのですが、毎週機能追加をコミットしているのは精神的にかなりしんどかったですね。特に最初はプロジェクトの立ち上げからだったので。初めてのお客様だったので信頼関係を構築するところからでしたし。1人プロジェクトでフットワーク自体は軽かったですが、管理コストも丸かぶりなので、非常に大変でした。要件定義フェーズもなくてざっくりと見積もり時に要件が決まっていただけなので、要件をつめつつ、画面デザインをきめつつ、実際にものを作るという感じでした。画面自体は1画面しかありませんでしたが、要素技術がChromeExtension、GoogleDataAPI、JavaScript、ちょっとだけGoogleAppEngineという感じだったので、ほんと調査ばかりしていて、実現可能か不安になる時も多々ありました。

今回思ったのはJavaScriptだけで画面を作れるのだなーということですね。JQueryのプラグインが充実していることもあるのだとは思いますが、JavaScriptとGoogleDataAPI（WebAPI)を連携させることでサーバーなしでも画面が作れちゃう時代なのだと実感しました。あと、今回は shin1ogawa さんの勧めでJavaScriptをオブジェクト指向で書いてみたのですが、とても書きやすいし、可読性もよくなってびっくりしました。

色々調査メモもたまっているので、ブログで書ければなーと思ってます。

最後に、まだプロジェクトが終わったわけではないのですが、お客様には恵まれたのだろうなーと思います。最後までしっかりと進めたいと思います。

Hadoop MapReduce デザインパターン1章〜3章

Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理

Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理

ずっと原書であるData-Intensive Text Processing With MapReduce (Synthesis Lectures on Human Language Technologies)を読もうとは思っていて、Pre-Production Manuscript(PDF)とかもチラ見していたのですが、Hadoop Conference Japan 2011 Fallで売っていたのでAmazonの予約をキャンセルしてその場で買いましたｗ

ちなみに、私のスペックを説明しておくとtry-hadoop-mapreduce-java - Hadoop MapReduceを気軽に試せるようにすることを目的としています - Google Project Hostingの作者なのでMapReduceの基本は理解しているつもりですが、仕事でMapReduceは書いたことが無いので経験値的には微妙です。あと、数学やら自然言語処理に関しては知識がないに等しいです。

1章　イントロダクション

  • Hadoop、ビッグデータ、言語処理、クラウド、スケールアウトみたいな単語について触れています。以前からHadoop界隈をウォッチしている方ならばだいたい知っていそうな話が載ってます。

2章　MapReduceの基礎

  • 象本ことHadoop 第2版のMapReduce周りを要約したような内容です。ただ、こちらからいきなり読んでもよく分からないのではないかという気もしました。象本を読んでから再確認する感じで読んだほうがよいと思います。
    • 象本は読んでなくてもある程度Hadoopを触ったりしていれば読める気もします。といっても、Hadoop触ってて象本読んでない人がいるとは思えませんが。。

3章　MapReduceアルゴリズムの設計

  • 本書で一番重要な章だと思います。そして、4章以降と比べてもそんなに難しくないです。
  • 擬似コードはフィーリングで読めますが、判例が欲しかった気もします。この記法は一般的だったりするのでしょうか？
in-mapper combiningパターン
  • combinerをmapperの中で実装するというパターンです。
  • combinerと違って必ず実行されるという保証があります。
    • combinerは最適化としてMapReduce実行フレームワークが複数回実行する可能性があるだけで、実際に実行される保証はありません。
  • メモリサイズについては一定間隔で出力すれば回避できます。
  • 以上を考えると、combinerを使うことって実際にはないのかなと思いました。実際に普段からMR書いている方に聞いてみたいです。
pairsとstripesパターン
  • 複数のキーにまたがる演算を行う場合のデザインパターンという理解です。例えば、group byでsumを求めるとして、その集約キーが2つある場合の実装方法です。2つある場合にmapper側ではレコードの集約キーと値をそのままreducer側に送るのがpairsパターン。mapper側で予め第2集約キー単位に値を合計した上で、第1キーでまとめてreducerに送るのがstripesパターンになる、、、という理解です。
    • ちなみに、pairsはキーと値のペアをそのままreducerに送るという意味で何となく分かるのですが、stripesはどのへんがstripesなのでしょうか。。。
  • キーが単一の場合はmapperの出力のキー側にキーを入れるしか選択肢が無いわけですが、キーが2つあると第2キーをキーの側に入れるという選択肢と、値の側に入れるという選択肢が生まれるということだと思います。
  • 書籍内では共起行列を例にして解説しています。詳細はHadoop MapReduce デザインパターンの3章まで読んでみた。 - watawata日記を読むのがよいと思います。共起行列の説明からサンプルコードまで載っていて素晴らしいです！
  • 両者のパターンにおいて当たり前ですがトレードオフがあり、pairsとstripesの中間のsub-stripesについても紹介されています。
    • ちなみに、sub-stripesのメモリの制約ってreducer側の話ですよね。本文では言及されていない気がしたので、誰か教えてくれると嬉しいです(^_^;)
      • 2012-08-18追記 改めて読みなおしたのですが、やはりreducer側の話ですね。stripesの場合はreduceメソッドである語に共起する全ての語の共起数をメモリ上に展開することになるため、ボキャブラリが大きくなるとメモリが足りなくなります。そのため、共起する語の側を複数のバケットに分割することで複数のreduceメソッドに処理が分割されるのでメモリの制約を回避できるようになります（当然、出力する際のキーからはバケットに分割した際のキー（ハッシュ値など）は除去することになります）。
order inversionパターン
  • reducer側で受け取るキーを制御することで、例えば相対頻度の計算ができたりしますよという内容です。象本の結合を読んでいれば、あーそうねーみたいな内容だと思います。
セカンダリソートと結合
まとめ

前編まとめ

まずは前編として1章〜3章について書きました。というのも、これを書くだけで3時間近くかかったので。。一応読み終えていたのですが、いざ書こうとすると読み直したり、色々考えたりする点が多く、時間がかかってしまいました。おかげで理解も深まったので結果オーライですね。

後編は残りの4章から7章を書く予定です。ちなみに、私自身は数学やら自然言語処理に関しては知識がないに等しいレベルなので、6章に関してはほぼ理解できませんでした。そんな私でも理解できた部分もあったので、その辺りについて書けるといいなと思ってます。

2011-10-10追記

後半はHadoop MapReduce デザインパターン4章〜7章 - n-3104の日記です。

2-legged OAuthについて調べてみました

最近Google Apps ScriptでSitesにMLの一覧を表示するというのをやってまして、その中で2-legged OAuthが出てきたのでちゃんと調べようと思っていました。そして連休中にUsing 2-legged OAuth with the Google Tasks API for Google Apps domain administrators - Google Apps Developer Blogという記事に出会いまして、ちょっと調べてみました。

2-legged OAuth

OAuthについてはJavaでTwitterのOAuthを書いてみました - n-3104の日記で調べていたのですが、要はユーザーIDとパスワードではなくトークンを利用して認証を行う仕組みです。そのOAuthにも2-legged OAuth（以下2LO）と3-legged OAuth（以下3LO）の2種類あって、Twitterの場合は3LOでした。3LOの場合はProvider、Consumer、Userの3者が登場し、ConsumerがProviderにアクセスする際にUserに認可してもらいアクセストークンをもらいます。一方、2LOの場合はUserからの認可というフローが不要になりアクセストークンも利用しません。ProviderはConsumerから発行されるConsumerKeyとConsumerSecretのみでConsumerにアクセスします。

実際に2LOによる実装という意味では、まずHTTPリクエストの中身については2-legged OAuthによるAPIアクセス mixi Developer Center (ミクシィ デベロッパーセンター)が、ソースコードという意味ではpythonで署名付きリクエストを送る(2-legged OAuth) « taichino.comが参考になります。

署名アルゴリズム

2LOについて調べていたら、OAuthの仕様について 〜署名？それっておいしいの？〜 (Yahoo! JAPAN Tech Blog)というページを見つけました。あまり意識していなかったのですが、OAuthで利用する署名アルゴリズムは3種類あるそうで、HMAC-SHA1の場合はService Provider(以後SP)側でConsumerkeyとSecret(秘密鍵)のペアをConsumerし、RSA-SHA1の場合はConsumer側で公開鍵と秘密鍵を生成し、事前に公開鍵をSPに登録しておくらしいです。

Appsの管理者向けコントロールパネルには署名をアップロードするUIがあったのですが、RSA用だと分かって納得しました。実際、OAuth: Managing the OAuth key and secret - Google Apps HelpにもRSA用と書いてありました。

HMAC-SHA1

もうちょっと深堀ということで、HMAC-SHA1そのものについて調べてみました。WikipediaによるとHMACはハッシュ関数を使って秘密鍵と組み合わせて計算するMACだそうですHMAC - Wikipedia。つまり、HMAC-SHA1はハッシュアルゴリズムにSHA1を利用して、OAuthの秘密鍵（共通鍵）からMAC（signature）を作るアルゴリズムのようです。より厳密な定義はRFC 5849 - The OAuth 1.0 Protocolを参照してください。

Appsにおける2LO

Google Appsで2LOを行う場合、ドメインに対する2LOという扱いになりますOAuth for Google Apps domains。ドメイン単位でOAuthを利用して認証するのは良いとして、実際にリクエストを送信したユーザーを特定する必要があります。例えばGoogle Documents List APIの認証にOAuthを利用してドキュメントを新規に作成しようとし場合、ドメイン単位の認証では誰のドキュメントと作成しようとしたのか分からなくなってしまいます。そのため、Appsではxoauth_requestor_idというパラメーターにメールアドレスをつけることで、どのユーザーとしてAPIをコールしたのか指定できるようにしているようです。詳細はExample: Accessing a Google Data API feedを参照してください。最初に出てきたUsing 2-legged OAuth with Google Tasks API for Google Apps domain administratorsはこのGoogle Tasks API版の記事で、サンプルソースにおいてxoauth_requestor_idを設定していることが分かります。

きんちゃん、ありがとう

リマインド 考えた 充電

主に家庭的な理由で、色々と疲れがたまっていたのですが、 @quindim の送別会に行くことで、とても元気をもらいました。特にLTを書いていて、かなり復活しました。ほんとありがとう、きんちゃん。

これまた家庭的な理由で、圧倒的に時間がなかったりするのですが、その中でもいろいろやっていきたいなーと思うようになりました。時間がない以上、取捨選択と単位時間あたりの生産性をどう向上するかがポイントになるのは明白なのですが、あんまりそういうことばっかり考えずに、やりたいことをやりたいときにやるのもありかと思いました。その時間がないという矛盾もあるのですが、矛盾とか気にせず、とにかく前に進めばいいかと思います。取捨選択と単位時間あたりの生産性向上という方向性でやった結果、疲れがたまるという結果になったので。