基本的には、以下のページを元に設定して進めていきました。

1. gitのインストール：port install git-core
2. Egitのインストール：Eclipse Git プラグイン ～ インストールからコミット、履歴の比較まで （良記事です）
3. Eclipse上でサンプルプロジェクトを作成
4. github上に同じ名前でリポジトリを作成
5. SSHのキーを作成しgithubに登録：Set Up Git （githubの公式ヘルプ）
6. EgitからgithubにPushするところ：Github Tutorial （Egitの公式ヘルプ）

ここまでは順調でした。で、Pushする際にgithubで作ったリポジトリのURIを指定してプロトコルをSSHにしてnextボタンを押した所で、”session is down”とか”cannot get remote repository refs”とかのエラーがでて、先に進めませんでした。（OSXのではなく）Eclipseのデザインでのパスワードを入れるポップアップがでたときもあり、ここにSSHのパスフレーズを入れてもだめ。プロトコルでhttpsを選べば進むようだったけど、せっかくなのでSSHでやりたい。

検索したところ、以下の掲示板で同じ問題に関する話題がありました。

• EGit – SSH Fails at Passphrase (when connecting to GitHub)

要は、環境変数に GIT_SSH=/usr/bin/ssh を追加してみて、ということ。そもそもOSXで環境変数の追加の方法がわからなかったので、

• Mac OS XでのJAVA_HOMEと環境変数の設定方法

上のページを参考にして環境変数に追加して再起動して再実行したところ、詰まっていたところで初めてOSXのいつものパスワードを入れるポップアップが出て、ここにSSHのパスフレーズを入力したところ、接続できました！！

ローカルで新しいbranchを作ってcommitしてpushしたのがgithubに反映できることも確認できました。もし同じような問題で詰まっている方がいれば、参考にしてください。

4.3 友人関係グラフの作成

ここでは、これまでに作成してきたデータを可視化させる方向に話が進みます。可視化することによってわかってくることがあるので、といったことですね。その可視化したものをソーシャルグラフ、と呼んでいます。

じゃあ例4-10をコピって…と思ったら本にファイル名が書いてない！あらソースなし？と思って著者のgithubを見たら、なんだ、ちゃんとありました（friends_followers__redis_to_networkx.py）。

このソースは、前節の例4-8のクロールのソースを用いて対象としたいtwitterアカウントのデータをRedisに入れてあることを前提として、特定のtwitterアカウント（これを引数で指定）がフォローしている人たちのなかで、相互フォローしている関係（引数で指定した人を含まなくてもいい）を、この本の1章でちょっと使ったnetworkxライブラリを使ってグラフのエッジとして追加していきそれをファイルに書きだす、というものです。

このソースを理解する上でのpython言語的ポイントは、

friend_ids = [fid for fid in friend_ids if fid in ids]

ですかね。if文つきのリスト内包表記です。わかってしまえばどうということはないのですが、日本語で説明すると、「friend_idsから一つづつもってきて、それがidsの中に含まれていれば、リストに残していく」となって、ソース内では、idsが引数指定したアカウントのuser_id＋そのアカウントがフォローしているアカウントたちのuser_idのリストで、friend_idsが、idsからひとりピックアップしたアカウントがフォローしているアカウントたちのuser_idのリストですから、ここでこの２つの積集合を取っており、それがとりもなおさず相互フォローの関係である、と。

これを前回に引き続き僕のアカウント（HOSONO_Junya）で実行したところ、

Processing user with id 14863108
Processing user with id 90241658
Processing user with id 48395404
Processing user with id 112571530
…

と834行（＝フォロー数＋自分）表示されて、outというフォルダのなかに、”HOSONO_Junya.gpickle”というファイルができていました。このファイル自体は、ソース内のオブジェクトをシリアル化したものなので、直に開いても仕方がありません。次の節の、例4-11のソースの入力として使うためのものですね。

…とはいえ、せっかく僕のアカウントの近辺での相互フォローの関係がわかったわけですから、ぜひ見てみたい！と思ったのですが、それはちょっと先の4.3.3でやってくれているので、ちょっと我慢しましょうか。

4.3.1 クリークの検出と分析

ここでは、前節で得られたデータをもとに分析しています。前節で相互フォローの関係が得られたわけですが、これはソーシャルメディアという視点からすると「魅力的な素材」だと書かれています。そしてここでは、そのその関係の有り様を考える上でのツールとして、クリークというものを利用しています。これによって、「グループダイナミクス」がわかると。この単語を本にそのままカタカナで表記しているということは、適切な日本語訳が見当たらなかった、ということかな？ 「そのグループにおいて、個々の間にどのくらい密接な関連があるのか」、といったあたりでしょうか。

クリーク自体については、詳しくはWikipediaなどを参考に（と本もぶん投げてますので…）。僕もクリークというもの自体を初めて知りましたが、ざっくりいうと、

• クリークとは「あるグループのなかから、どの２名をとっても関連付けられている（ここでは相互フォローしている）サブグループをとりだしたもの」
• 最大クリークとは「クリークの中でその対象者の数が一番多いもの」

と、理解しました。間違ってたらぜひコメントで指摘してください。

で、ここのソースの例4-11（friends_followers__clique_analysis.py）は、例4-10の結果をもとに、クリークの数や平均サイズ、最大クリークを算出してくれます。

で、実行したところ、

Num cliques: 832
 Avg clique size: 2
 Max clique size: 3
 Num max cliques: 125
People in all max cliques:
 [
 "HOSONO_Junya",
 "hsksyusk"
 ]
Max cliques:
 [
 [
 "HOSONO_Junya",
 "hsksyusk",
 "thinktheearth"
 ],
 [
 "HOSONO_Junya",
 "hsksyusk",
 "adanao"
 ],
 …

となりました。…３!? 最大クリークが３!? (２度見した)　小さ！もっとフォロー数ふやせよ俺！（ちなみに@hsksyuskさんとは、いま働いているNGOにボランティアで関わってくれているSEさんです）そのサイズ３のクリークが125個あるということは、僕とhsksyuskさんと後一人、という3人組が大量にある、ということですね。

うーん、ちょっとこれだけではサンプルとして寂しいので、フォロー数/フォロワー数が違えば結果も変わってくるかもしれないということで、僕が働いているNGOの公式アカウント（@ngo_jvc）で試してみましょう。フォロー数＝1276、フォロワー数＝3666です。

まずは例4-8でRedisにデータを作り(depth=1で実行、7274件のデータが作成された)、例4-10で相互フォロー関係を抜き出し、例4-11でクリークを見つける…っと。結果は以下のようになりました。

Num cliques: 1274
Avg clique size: 2
Max clique size: 4
Num max cliques: 43

それでも最大クリーク＝4か…。ふと思いついて、もういちど僕のアカウントで例4-11を実行したところ、結果が変わってきました。

Num cliques: 831
Avg clique size: 2
Max clique size: 4
Num max cliques: 43

…そうかそうかなるほどなるほど。そもそもRedis内のデータが足りていないために（両方共にdepth=1でしか実行していないからかな）、正確な（というか完璧な）結果が得られていなかったわけですね。

うーん、depthを増やして実行してみるのは後日の宿題としておくとして、先に進みましょう。

4.3.2 Infochimpsの「強いリンク」API

ここでは、twitterのデータを取り扱う手段のひとつとして、Infochimpsというサービスを紹介しており、過去のtwitterデータをAPIで取得できるとのこと。Strong Links APIでは、もっともやりとりしている（おそらく＠言及している？）相手を教えてくれるということで、それを使っています。事前にサインインが必要とのこと。

例4-13（friends_followers__infochimps_strong_links.py）を実行してみました。ソース自体は単にStrong Links APIをRESTで実行しているだけですね。

HOSONO_Junya's Strong Links
 ------------------------------
 hsksyusk 5.478303
 HOSONO_Junya 4.832576
 suzukinao 3.1820507
 kanaedoi 2.982051
 tokko 2.982051
 suesi 2.95
 segatomo 2.9320507
 tksmmshr 2.8642135
 j_machikado 2.8642135
 chusoken 2.7071068
 momonico 2.6642137
 dskfj 2.6142135
 MorikawaW2C 2.45
 …

となりました。自分自身の名前があるのは、たぶん旧式RTのためだと思います。僕のtwitterの使い方として独り言が多い（＠言及しない）ので、＠言及が多い人と比べてみると面白いかもしれませんね。

Infochimpsには他にもたくさんAPIが有りそうなので、探ってみるのもいいでしょう。

4.3.3 3Dグラフへの対話的な可視化

さて、さきほど後回しにした可視化をやってみる節です。

本では、可視化するツールとして、Ubigraphを紹介してくれています。3D、らしいですね。公式サイトからOSにあわせてダウンロードしてきて解凍しましょう。サーバを実行して、demo.pyを動かすまでやってみましょう。別ウィンドウが開いて、マウスで動かせる図形がでたところまでできれば、準備完了ですね。

例4-15（friends_followers__ubigraph.py）では、twitterアカウントを２つ引数にとって、その２者がともに所属する最大クリークを3Dで表示してくれるみたいです。

例によってコピペしてきてHOSONO_Junyaとngo_jvcを引数にして実行…すると、エラーが出ました。

Traceback (most recent call last):
File "friends_followers__ubigraph.py", line 8, in <module>
import ubigraph
ImportError: No module named ubigraph

おっと、pythonのライブラリが入ってませんでした。さきほど解凍したフォルダのexamples/Python/ubigraph.pyをソースと同じフォルダに入れて再実行したら、またエラー。

Traceback (most recent call last):
File "friends_followers__ubigraph.py", line 13, in <module>
g = nx.read_gpickle(SCREEN_NAME + '.gpickle')
File "<string>", line 2, in read_gpickle
File "/Library/Python/2.7/site-packages/networkx-1.6-py2.7.egg/networkx/utils/decorators.py", line 173, in _open_file
fh = _dispatch_dict[ext](path, mode=mode)
IOError: [Errno 2] No such file or directory: 'HOSONO_Junya.gpickle'

あらら、今度はgpickleのファイルが読めなかったです。さっきのままoutフォルダに入ってるので、ソース内のファイル名の前に”out/”と付け足して実行。今度はうまくいきました。

先ほどの別ウィンドウに出てきたのが以下のような画面。

そうか、最大クリークが43個もあるので、ほぼ球形のような図になってしまいました。描画もちらついてるし。でもマウスでぐりぐり動かせます。

4.4 まとめ

この章のこれまでの流れを振り返って、他の章とおなじく「こんなこともやってみれば？」という宿題が書かれてます。まぁ後日、ということで。

よし、とにかく『入門ソーシャルデータ』第４章、最後までやってみました。章の後半は、とにかくRedisにデータを入れてはじめて分析に役立つ、という流れになってきていたので、どんどん入れていったほうが面白そうですね。

最後までお付き合いいただきましてありがとうございました！それでは勉強会当日お会いしましょう！

• 第4回「入門 ソーシャルデータ」真面目に勉強する会 @神泉(渋谷)

このイベントは、オライリーの『入門ソーシャルデータ』を参加者同士で一章ずつ担当して読み進めていこう、という連続勉強会で、この日ではそのうちの第4章を担当することになっています。

それに先立って、事前にこの章をひと通り読み進めてみましたので、その過程を書き留めていきます。参考になれば幸いです。書いてみたら長くなったので2回に分けます。これはその1回目。

まず、この本では記載されているソースはすべてpythonという言語で書かれていますので、python環境もOSなどにあわせて用意しておきましょう。なるべくバージョンは新しいほうがいいと思います。ちなみに僕の環境は以下のとおり。

• OSX Lion 10.7.2
• python 2.7.1 (OSXでのpythonのバージョン切り替えについてはこちらに記載)
• Eclipse Herios SR2 + PyDev など（コマンドラインでやる人は必要ないでしょう）

（追記：pythonのバージョンは、本にあわせて2.7系がベターでしょう。@iwaimさんご指摘ありがとうございます）

おっと、この章を読み進めるには、とりあえず以下のpythonライブラリも必要となってきます。とにかく用意しましょう。

• twitter （これがなければ始まらない。この本の5ページにインストール方法の記載あり）
• cPickle（シリアル化ライブラリ）

そして最初に、この章でなに取り扱うのかを確認しておきましょう。ここでは、本の91ページにあるように、

• （twitterで）フォローしている/されているユーザーは何人いるか
• フォローしているけれどもされていないユーザーは誰か
• フォローされているけれどもしていないユーザーは誰か
• ネットワークのなかでフォロー関係のもっとも多いユーザー、少ないユーザーは誰か
• 「相互フォロー」（フォローし合っている関係）している相手は誰か
• 自分のフォロワー全員と彼らのフォロワー全員から考えて、自分がリツイートしたときにどのような影響があるか

ということを取り扱います。

ちなみに、これ以前の１〜３章については、今回の勉強会の主催者の方が設置してくださっているGoogleグループ「集合知の会」に、各回のプレゼン資料が掲載されていますので、参考にしてみてはいかがでしょうか。

それでは、章立てに従って見ていきましょう。

4.1 RESTfulとOAuthを着込んだAPI

ここでは、twitterのAPIはRESTfulでもあること、twitterアカウントの情報を得る際には、twitterのいわゆるアカウント名（=screen_name）のほかに、アカウントごとに固有な整数（=user_id）を利用することもできる、ということが書かれてます。

そして、ユーザー認証が必要なtwitterのAPIを利用するには、OAuthを利用する必要がある、として次に進みます。

4.1.1 君が私のパスワードを知っているはずがない

ここでは、twitterというよりも、OAuth自体の説明ですね。様々なウェブサービスはその認証機能としてOAuth 2.0を採用し始めており、twitterも2010年夏からOAuth1.0aを採用しています（2.0はまだの様子）。

OAuth自体のことを理解するためには、この章を読む他にも、下記のようなページを読み進めるのもいいと思います。

• ゼロから学ぶOAuth (gihyo.jp)
• APIアクセス権を委譲するプロトコル、OAuthを知る (@IT)
• 非技術者のためのOAuth認証(?)とOpenIDの違い入門 (コメント欄も読みましょう)

要は、本にあるとおり、「一言で言えば、OAuthは、ユーザー名とパスワードを共有せずに、あるアプリケーションが格納したデータに別のアプリケーションからアクセスできるようにするために、そのアプリケーションに権限を認める手段を提供する」もの。そしてその手段を、ユーザー認証として利用している場合もある、ということですかね。

たとえば、今回の勉強会の告知に利用されているatndさんも、OAuthを利用してユーザー認証をしている、といっていいものだと思います。

4.2 無駄がなく必要最小限なデータ収集マシン

さて、話はtwitterに戻ります。今回の『入門ソーシャルデータ』を読み進める上でありがたいのは、掲載されているソースのなかで（〜.py）とファイル名が付いているものに関しては、著者のgithubでまんま公開されていること。コピペで動作確認できるわけですね。

さっそく例4-2のソース（friends_followers__get_friends.py）をコピペして実行…と思ったら、いきなり本のソースとちょっと違ってるやんけ！ githubのこのソースの履歴を見ると、“Fixed a minor bug in reporting output, Mostly style tweaks”とあって、consumer key と consumer secret を引数として渡すようになっていました。ふむふむ。

ここで、本にも記載がありますが、これ以降のソースを実行するには、twitterの開発者用サイトに行って、「新しいアプリケーションを作成する」ことで、この consumer key と consumer secret を取得する必要があります。もちろん、twitter アカウントも必須。

この画面ですね。

ここで、Nameは独自のものを指定する必要があるみたいです（ここではなにも考えずに”socialdata_hosono”としました）。無事アプリケーションを作ると、consumer key と consumer secret が発行されました。

これを、試しに自分のtwitterアカウントのscreen_name (HOSONO_Junya)と一緒にさっきのソースの引数として渡して再実行！　コンソールには以下のような画面で止まって、

Hi there! We're gonna get you all set up to use MiningTheSocialWeb.
In the web browser window that opens please choose to Allow access.
Copy the PIN number that appears on the next page and paste or type it here:
Opening: http://api.twitter.com/oauth/authorize?oauth_token=(文字列)
Please enter the PIN:

それとは別にブラウザが開き、よく見かける下の画面が出てきました。

なるほど、twitterさんに、

• タイムラインのツイートを見る。
• フォローしている人を見る。

この２つの機能を、socialdata_hosono というアプリケーションに使わせてやっていいですか？という問い合わせが発生したわけですね。許可するためにアカウント名とパスワードを入力すると、PINが発行されました。

コンソールに戻ってこれを入力すると、

Fetched 833 ids for HOSONO_Junya
[124190170, 342836805, 5373072, 384222380, 137886908, 24066081,
167287360, 313359626, 308796953, 338254966, 165748489, 14491664,
3776671, 14655252, 41823348, 14357291, …

と表示されました！ 833というのは、僕のtwitterアカウントの「フォローしている数」ですので、フォローしている人たちのuser_idのリスト（pythonでいうところのリスト）が得られたことになります（この本内やtwitterの公式ドキュメント内でのfriendsというのは自分がフォローしている人、という意味ですね）。

（ちなみに、上の表示の"Fetched〜"の部分だけ標準エラー出力に書き出しているあたりがちょっと親切ですねw）

なお、本に記載もありますが、ソース内で使っている /friends/ids API は一度の呼び出しで5000のIDを返すそうです。このソースではそのたびに"Fetched〜"の行を出しつつループする、という形になっており、上限を10000としています。そして、こうしたAPIの呼び出しには回数制限があり、350回/時とのこと。同様の記載が、以下のサイトにもありました。

• SourceForge.JP > ソフトウェアを探す > Tween > Wiki > API制限について

なので、大量のフォロワーを持つアカウントを対象にこうしたAPIを利用する場合にはそれなりの準備をしなければならない、ということですね。

4.2.1 リファクタリングのための非常に短い幕間

ということもあって、そのあたりの準備を著者はあらかじめしてくれています。偉い！ここではOAuthを用いたログイン部分と、よく使われるAPIをモジュール化＆公開してくれています。

• twitter__loginモジュール
• twitter__utilモジュール

これを使えば、ソース内で自分のやりたいことに集中できるというわけですね。ソースが短くなっていることがわかると思います。ありがたく使わせていただきましょう。上記リンクからダウンロードして、自分のソースと同じフォルダに置いておけばいいでしょう。ファイル名もそのままにしておくのがベターですね。

例4-3（friends_followers__get_friends_refactored.py）は、例4-2をこの２つのモジュールを用いて書き換えただけのものです。こちらもgithub版のソースは本からちょっと修正されていて、引数としてフォロー数の上限も引数で渡すようになっています。

ソースを見て、「…引数がアカウント名とフォロー数上限の2つだけ？はて？」と思いつつ実行したら、案の定エラーが。tracebackが吐かれて、

twitter.api.TwitterHTTPError: Twitter sent status 401 for URL:
oauth/request_token using parameters: (oauth_consumer_key=
&oauth_nonce=(数字)&oauth_signature_method=HMAC-SHA1&oauth_timestamp=
(数字)&oauth_version=1.0&oauth_signature=(文字列))
 details: Failed to validate oauth signature and token

とのこと。要はOAuthに失敗しましたよと。ソースを見ると、

# You may need to setup your OAuth settings in twitter__login.py

とあるので（書籍版にも書いてありますね）、twitter__login.pyの最初の部分に customer key と customer secret を直書きして再実行、再びPINが発行されて、無事friendsが取得できました。

もちろん、このライブラリを使ったとしても、API制限自体が消えるわけではないので、大量のデータを取り扱う場合にはそれなりの時間を使える時にしたほうがいいでしょう。

4.2.2 Redis：データ構造サーバ

この節では、APIを用いて得られるようになったtwitterの各種データを取り扱うために、Redisというデータベースの導入をする、としています。その心は、大量なデータを取り扱うため、ともう一つ、集合演算を使いたいため、ということらしいです。

僕はRedisを今回初めて知ったのですが、この本の3章でもでてきたCouchDBなど同じく、KVS (Key-Value Stored)なデータベースとのこと。要はハッシュデータのようなものを取り扱うのに長けているといったものでしょうか（詳しい人コメントお願いします）。

なにはともあれ、Redisをインストールしましょう。公式サイトのダウンロードページにインストールの指示があり、これに従って簡単にインストールできました。そしてコマンドラインからサーバを起動して専用クライアントから操作できること、までの説明が公式サイトにあります。

次に、このRedisをpythonから利用するためのライブラリも、sudo easy_install redis であっさりインストール完了。

本の101ページの一番下のソースは、"screen_name1$friends_ids"というキーに対して、pythonのリスト内包表記を用いて、1,2,3…と順繰りに追加（sadd）していってそれを表示(smember)する、というだけのことですね。保管されるデータは、

• キー："screen_name$friends_ids"
• 値：set(['1','2','3'...])

という一組になります。

4.2.3 初歩的な集合演算

さて、ここでは、そもそもなぜ集合演算を使うのか、ということを確認しています。例4-2のソースにあるように、この章で取り扱う twitter API で得られるデータは、フォロワーの一覧などその多くはデータが複数集まったもの＝集合、です。そしてそれらに対して集合演算を用いることで、意味のある情報を得ようというわけですね。例として、

Friends = {Abe, Bob}, Followers = {Bob, Carol}

というtwitterユーザーに対して、

というような情報が得られるわけですね。これらが、記事の最初に書いたこの章で取り扱おうとしていた情報そのもの（の一部）であることがわかると思います。

そしてこの本では、pythonの（リストではなく）set型を用いてソース内で集合を取り扱っています。

4.2.4 フォローしている／されている関係を測るマシン

この節の例4-4は、先の例4-2のソースに対して取得したデータをRedisに格納し、そこから上のような集合演算をして結果を表示するものです。これを実行すると、

HOSONO_Junya is following 833
HOSONO_Junya is being followed by 612
548 of 833 are not following HOSONO_Junya back
327 of 612 are not being followed back by HOSONO_Junya
HOSONO_Junya has 285 mutual friends

と表示されました。上から、フォロー数(Friends)、フォロワー数(Followers)、フォロー返ししてくれていない数（上の表での差集合１）、フォロー返ししていない数（差集合２）、相互フォロー数（積集合）となります。激しくフォロー返しされていないのがわかりますね…orz

なお、この例4-4のソースを理解する上でキーとなるのは、

• "functools.partial" というのが何をしているのか
• Redisに格納されるデータがどんな感じか

ということでしょう。

まず"functools.partial"ですが、うーん、これは正直自分でも正確に理解できているかどうかわかりませんが、ざっくり言うと「特定の関数を一部分だけ修正して新しい関数を作り出している」ということでしょう。専門用語では「部分適用」というらしいです。それをこの本では「ラッパー」という言葉で表現している、と。そしてここでは、

• 元の関数＝_getFriendsOrFollowersUsingFunc (twitter__utilライブラリ内)
• それを元に新しく作られる関数＝getFriends と getFollowers

がそれに該当します。要は、関数が２つほしいけど中でやってることはほとんど同じだからその部分だけ先に作って最後に呼び出し部分を変えるだけで対応しようぜ（コード再利用のためにね）、ということでしょうかね。

このfunctools自体に関しては、以下のページなどを精読すると理解が深まるかもしれません。

• functools – 関数を巧みに操作するためのツール
• 9.8. functools — 高階関数と呼び出し可能オブジェクトの操作

はっきり言ってこの部分を正確に理解すること自体は、「この本のこの章を読み進めていく」という目的においてはそんなに重要ではないと思います。「へー、そんなこともできるだね」程度でいいと思います。本筋とは関係のない箇所でつまずいてそこで止まってしまうのはもったいないですから。もちろん、理解できることに越したことはありませんが。

どうも、CやJavaといった一般的な「手続き型プログラミング言語」を経験した人がpythonをやる上でとっつきづらく思える部分に、こうした「関数型プログラミング言語」的な要素がそこかしこに出てくるからなのかもしれません。リスト内包表記しかり、lambda式しかり、そしてこのfunctoolsしかり。以下のページにそのあたりのことがちょっと書かれていました。

• 魅力的なPython: Pythonでの関数プログラミング: 第1回
• Python における関数型プログラミング のための functools, itertools (1) – Haskell と同じ名前の関数たち

閑話休題。つぎは、Redisに格納されるデータがどんな感じか、ですね。これは、ソースの最後に以下のようなprint文を入れて実行すればわかりますね。

print r.smembers(getRedisIdByScreenName(screen_name,'friend_ids'))

また、getRedisIdByScreenName関数の中身などから、Redis内には、上で作った２つの関数を実行することで、

• キー："screen_name$(引数で指定したscreen_name)$friend_ids"
• 値：set([(フォローしている人たちのuser_id)])

と、

• キー："screen_name$(引数で指定したscreen_name)$follower_ids"
• 値：set([(フォロワーたちのuser_id)])

という２つのデータが格納されます。Redisのクライアントのkeysコマンドなどからも確認できるでしょう。そして、次にこの２つのデータの値に対してRedisの機能である集合演算をかけている、というわけですね。

そして、これまでは取得するデータはたいていuser_idの集合のみでしたが、次の例4-5では、特定のuser_idのtwitterアカウント自体の各種ユーザー情報を取得しています。これもgithubからソース（friends_followers__get_user_info.py）をコピペしてくるだけで実行できます。結果はJSON形式になります。これを実行すると、

• キー："screen_name$(引数で指定したscreen_name)$info.json"
• 値：引数で指定したscreen_nameのユーザー情報（JSON形式）

いう２つのデータがRedis内に作られます。これは、あとからscreen_nameとuser_idのどちらからでも素早くユーザー情報を取得できるようにするため、でしょうね。

4.2.5 共通してフォローしている／されているユーザーからの類似度の計算

この節では、複数名のユーザーを指定して、その人たちが共通してフォローしている人たち／共通してフォローされている人たち、を見つけます。異なるユーザーのフォロー／フォロワー間で集合関数を使うことで見つけることになります。

これまでどおり例4-7（friends_followers__friends_followers_in_common.py）をコピペしてくるわけですが、その実行の際には、対象とするユーザーのフォロー／フォロワーのデータをあらかじめRedis内に入れておかなければなりません。具体的に言うと、例4-4を対象ユーザーで実行しておけばOKです。先ほどの部分適用して作られた関数がRedis内にデータを格納してくれますから。そうしないと、データが無いので単に0件と返ってくるだけです。

4.2.6 影響力の計測

twitterの機能のなかで特徴的なもののひとつに、リツイートがあげられます。気に入った他人のツイートを自分のフォロワーに「転送」する機能ですよね。これによって、ある特定のツイートが連鎖的にリツイートされると、短期間で爆発的に広まることになります。そしてフォロワーの多いユーザーにリツイートされると、より広く伝播されて大きな影響を生み出すことができる、というわけです。

この節では、そうした影響力をフォロワー数によって測ってみよう、というものです。例4-8（friends_followers__crawl.py）は、ある特定のユーザーからスタートして、そのフォロー／フォロワーの情報をすべて取得＆Redisに格納し、そしてそれら一人ひとりに対してまたフォロー／フォロワーの情報をすべて取得＆Redisに格納し、そして…と、繰り返していきます。

なので、これを実行すると、Redis内のデータが一気に増大します。何階層まで探索するかは引数のdepthで指定できますが、僕のアカウントでdepth=1（直接のフォロー／フォロワーだけ）で実行したら、一分ほどで終了して、Redis内に2322件のデータがあらたに登録されました。

…うっかりdepth=10とかで実行すると、はっきり言ってどういう事態になるかわかりません。たぶんAPI制限に引っかかりながらも制限がリセットされる一時間おきにちょっとずつ進んでいって、メモリとHDDをRedisデータが喰い潰していく、という感じでしょうか。だからこそ、このソースでは一度のフォロー数などの探索での上限数を設けています。なんにせよ、ちょっと気をつけて実行しましょう。

しかしこのソースでは、あくまでデータを取得＆格納しただけで、影響力としてはさっぱりわかりません。そこで次の例4-9（friends_followers__calculate_avg_influence_of_followers.py）では、対象ユーザーのフォロワーのなかでフォロワー数の多いトップ１０と、全フォロワーの平均フォロワー数を計算しています。なお、このソースではPrettyTableというライブラリが指定されているので、素直にeasy_installしましょう。

同じく僕のアカウントで行ったところ、以下のように結果になりました。

The top 10 followers from the sample:
 +----------------+---------+
 | Date | Count |
 +----------------+---------+
 | hatoyamayukio | 608,303 |
 | shuzo_matsuoka | 258,605 |
 | 38sun3 | 250,422 |
 | ktamiya | 240,826 |
 | LIVESTRONG | 203,574 |
 | tsuda | 196,778 |
 | sasakitoshinao | 145,352 |
 | myen | 137,497 |
 | wakita_tamaki | 70,913 |
 | asao_keiichiro | 68,583 |
 +----------------+---------+
The average number of followers for HOSONO_Junya's followers: 6,856

トップは鳩山由紀夫元首相か…あんまり最近見かけないようなw

次回に続く。

さて、長かった4.2章もこれで終わりです。ずいぶん長くなったので、続きは別エントリーにします。できれば明日中には更新します。

例えばこんな入力から、

 strict digraph {
    "ノード1" -> "ノード2" [label="エッジA"];
    "ノード2" -> "ノード3" [label="エッジB"];
    "ノード2" -> "ノード4" [label="エッジC"];
 }

こんな感じの絵が描けます。

「…あれ、これって何かに使えるような…」と考えて、「そうだ、これを使ってJリーグの選手の今オフの移籍情報を可視化してみると面白いかも！」と思いつきました。

幸い、世の中にはJリーグやJFLの選手の移籍情報を蓄積してくれている「ら」情報というものがありまして、こちらのサイトで最新情報をまとめてくれています。

上記のサイトのデータ（1/14時点）をもとに、各クラブを「ノード」に、クラブ間を移籍する選手を「エッジ 」としてDOT言語に変換してみたデータを可視化してみました（赤線＝現役日本代表、青線＝大学生、緑線＝ユース／高校生）。それが下の画像です！

（生成パラメータ：layout=fdp,splines=true,overlap=false, sep=30）

どうですか？　この画像から以下のようなことがわかってきます。

1. まず、想像以上に大量の線が描かれました。この線一本一本がひとりの選手の移籍になります（同じチームから同じチームに複数人移籍した場合も今は一本にしてあります）。そう考えてみると、いかに今オフの移籍が多いかがわかります。
2. 最も矢印の行き来が多いのはJ1<–>J2ですが、J2->JFLも結構多いのが見て取れます。活躍の舞台をJ2からJFLに移す選手が多い、ということですね。
3. 1/14時点においても、矢印の行き先が「未定」の選手が多いこともわかります…。
4. 現役の日本代表選手の移籍はあまりないこと（槙野選手、今野選手、ハーフナー・マイク選手、李忠成選手くらい？見落としてたらすみません）。
5. 大学生や高校生、ユースからJリーグやJFLにやってくる選手が予想よりも多かったです。また、今オフは韓国の大学からの加入も想像以上に多いですね。兵役の問題はどうするのかなぁ？

うーん、やっぱり我ながらもっと見やすくしたいですね…。そもそも僕自身がGraphvizの扱いにまだ慣れていないので、「こういうデータなら、こうすればもっときれいに可視化できるよ」という方法をご存知の方はぜひ教えてください。そうすれば、もっとたくさんのことがわかってくると思います。後日、元データのDOTファイルも公開したいと思います。それと、今回は手作業で一気に変換した（半日かかりました…）のですが、やっぱりスクレイピングでやりたいですね。

また、各クラブの塗り色ですが、「だいたいこんな感じかな〜」という程度で塗っていますので、もし変なようであればこちらのページの色情報を参考にして「この色にしてほしい」ということをtwitterの@HOSONO_Junya宛かこの記事のコメントでお知らせください。JFLクラブのファン・サポーターの方もぜひお願いします。

Jリーグ&JFLのファン•サポーターにとって、この時期は自分の応援しているクラブの移籍情報に一喜一憂しますよね（僕もそのうちの一人です）。そのときに、こんなデータもちょっと参考にしてみてくれると嬉しいです。

いくつかのブログを見たところ、「python_selectを使え」的な記述をよく見かけますが、どうやらこれは古い情報のようで、「python_selectは死んだ」なんて記事もありました。どうやらMacPortsの仕様変更とのこと。

なので、まずはMacPorts自体をアップデート。

sudo port selfupdate
sudo port sync

で、現在切り替えられるpythonを確認するために

 port select --list python 

とすると、

Available versions for python:
none
python25
python25-apple
python26-apple
python27-apple (active) 

なような表示がでてきます。現在activeなのは2.7、ということですね。バージョンを切り替えるには、

sudo port select --set python python25

で切り替わります。

Available versions for python:
none
python25 (active)
python25-apple
python26-apple
python27-apple 

これで出来ました。

また、ライブラリを読み込みeasy_installも、おそらくコマンド実行時にactiveなバージョンのpythonでのみ使えるようにインストールされるものと思われます。easy_installでインストールすると、 /Library/Python/(バージョン)/site-packages/ 配下に格納されるようです。

eclipseでも切り替えらえるように

GAEの開発にはeclipseを使っていますが、python2.7系を使う時にもeclipseが使えると便利ですよね。

それには、Preferences の画面から PyDev の Interpreter – Python を開きます。すると、現在使えるように設定されているバージョン（のインタプリタ＝実行ファイル）が表示されますので、ここに利用したいバージョンのpythonの実行ファイル（port select で切り替えておいて which pythonで所在はわかりますね）を Add してやると、該当するライブラリをPYTHONPATHとして読み込んでくれます。便利！

そして、該当プロジェクトの Properties の画面から PyDev – Interpreter/Grammar を開きます。そこで、Interpreter の欄に先程設定したものを指定すると、そのバージョンのpythonで実行してくれる、というわけですね。一応、Grammar Versionもあわせておいたほうがいいでしょう。

これで、コマンドラインからeasy_installしたライブラリをeclipseでも使えるようにもなりました。

とりあえずこれで切り替わってるように思えますが、もし間違ってたり「もっとこうしたほうがいいよ」ということがありましたらコメントしてもらえると助かります。

• マシン：MacbookPro 15-inch, Early 2011
• OS：OS X Lion 10.7.2
• IDE：Eclipse Helios SR2
  • 追加インストールしたもの：PyDev for Eclipse, Google Plugin for Eclipse 3.6
• 開発言語：python 2.5.6
  • Lion上だとデフォルトは2.7系だったので、GAE開発のためにmacportsで入れなおした記憶があります。
• SDK：GoogleAppEngine SDK 1.6.1
• 利用するウェブアプリケーションフレームワーク：Django 1.2.5 (SDK同梱のやつ)
• DjangoテンプレートではHTML5を使う予定。

といったところですね。

とにかく、自分にとって新しい技術を使って作ることでそれらを習得することも大きな目的の一つです。特にpython/Django/GAE/HTML5あたりは自分にとって全部初物です。

今後も、開発時の記録（主に技術面・設定面）などをぼちぼち更新していきたいと思います。botの公開目標は一応3月中旬なのですが…できるのか俺？

昨年の12月15日、atndさんで見つけた、以下の勉強会に出てきました。

第13回「集合知プログラミング」真面目に勉強する会 @外苑前

きっかけは、「自分が働いているNGOの支援者データベースに蓄積された情報から、より有意義な情報を見つけるためにどうすればいいか」と考えていたことでした。「それには、いま現在自分が持っている知識とは全く別の視点が必要ではないのか？」と思っていたこともあります。「もしかしてそれが集合知なのかも」ということですね。

とはいっても、この勉強会は一冊の本『集合知プログラミング』を参加者で輪読していく連続もので、しかもこの回が最終回。ということで、それでも参加OKなのか主催者のひとりであるKshi_Kshiさんにtwitterで問い合わせたところ、快諾をいただきましたので参加してきました。当日の朝に買った本を持って（汗）。

勉強会では、簡単な自己紹介のあとに、Kshi_KshiさんがLDA(Latent Dirichlet Allocation)の紹介をされてました。これまでの回のフォロー、といった位置づけだったようです。が、いきなりで正直よくわからなかったです…。参考となるスライドを紹介されたましたのでそちらを参考にしてください。

その後は、最終回ということもあってか、自習の時間が長く取られており、参加者それぞれが自分で設定した目的のために黙々と作業する、というスタイルでした。

自分では、とりあえずその日の朝に買ったばかりの本を読んで、集合知を扱う際には教師あり学習と教師あり学習とがあること、自分の目的から言えば教師なし学習があっていること、本の目次から言えば、

• 3章　グループを見つけ出す
• 10章　特徴を発見する

が該当するのでしょうか。そして、実際のデータを思い浮かべて、それが何に使えるかを考えることに時間を費やしました。でも、やっぱりちょっとは手を動かしつつ実際のデータを使ってみて感覚をつかみたいところでしたが、当日はそこまでたどり着きませんでした。

自習時間の後に、各自なにをやっていたかを共有して終了しました。本を読み進める人、ひたすら動くものを作る人などさまざま、けっこう自由な感じですね。

とにかく、当日勉強会に参加された皆様、（今更ですが…）お疲れ様でした。大変刺激になりました。かなーり畑違いな人間を受け入れてくださってありがとうございました。

なお、この勉強会の参加者を中心としたGoogleグループもあるので、興味のある方は登録してみてください。過去の勉強会のときのプレゼン資料も共有されていますよ。

Googleグループ：集合知の会

次回、『入門ソーシャルデータ』に続く

なお、この勉強会はこの回で終わり。次からは、『集合知プログラミング』の続編と位置づけられているらしい『入門 ソーシャルデータ』をまた輪読形式で進めていくとのことで、そちらにも参加する予定です。

第1回「入門 ソーシャルデータ」真面目に勉強する会 @外苑前

ただし、こちらの本はタイトル通り、現在広く利用されているソーシャルサービス（TwitterやFaceboo、LinkedInなど）データのデータを取り扱うものなので、自分の当初の目的とはちょっと離れるかもしれません。でも、個人的にtwitterbotを作っている最中ですし、なによりも「約2時間集中せざるをえない空間」というのが新鮮だったので、今後もなるべく参加していきたいと思います。

以前別ブログでもやっていましたが、ウェブサービスの作成過程の記録を残していこうと思います。コードネームはSK。サッカーに関するものです。それ専用のカテゴリも作りましたのでそちらでどうぞ。

開発環境は、先日買ったmacbookpro上でつくっていきます。バックエンドはGoogle App Engine。もういい加減使えるようにならないと。言語はpython。いつのまにかGAEでdjangoの1.2が使えるようになっていたので、これも使います。

さて、こんどこそ一年以内で公開にこぎつけたいと思います。

たんにエクスポート/インポートしただけなので、下記の作業はこれから手作業で行います。

• 画像ファイルの移行
• 記事内のURLの変換
• .htaccessでも301転送設定

以前はMovableTypeの勉強を兼ねて自分のブログでいろいろしていましたが、そろそろその役目もなくなってきたこともあり、またいままでは,勤め先のドメイン内に置いていたこともあって、単語検索的にもあまりいい影響もあたえないような気がしていたので、いっそのことということでwordpress.comに移行しました。

今後はもうブログ自体の仕組み自体よりも記事内容に集中するようにしたいです…

ちなみに、単にシステムごと MT5 にアップグレードしたのではなく（そういう記事は検索するとたくさん出てきますね）、ブログ単体で MT4 から MT5 に移しました。システムごとアップグレードしたほうが楽なのでしょうが、しばらくは MT4, MT5 両者の並行運用が必要なので、ブログ単体だけの移行が必要になった次第です。

また、いわゆるMTの標準機能にある「バックアップ/復元」を使おうかとも考えましたが、これは移行元/先のMTのバージョンが同じであることが推奨されているので、今回は利用しませんでした。

以下、実際に行なった移行作業になります（多少順序は前後してたかも知れません）。

1. MT5 で移行先ブログを作成する（URL指定はMT4の現行ブログとは別にする）
2. 現行ブログで「記事のエクスポート」を行う
   1. これにはブログ記事、コメント、トラックバックが含まれる
3. エクスポートしたデータを、移行先ブログで「記事のインポート」を使ってインポートする
4. 移行先ブログにつくられるデフォルトのテンプレートをすべて削除する
5. 移行先ブログで、現行ブログと同じようにテンプレートを設定する
   1. 現行ブログでは、もともと各テンプレートは「ファイルにリンク」させていたので、これらのファイルを一旦ダウンロードする
   2. 移行先ブログのフォルダ内にダウンロードしたファイルをアップロードする
   3. 新規テンプレートを作成する際に、アップロードしたファイルをリンク先に指定していく
   4. この時点で、移行先ブログ側に足りないプラグインがあることがわかったりするので、必要に応じて追加・設定していく
   5. この時点で、テンプレート内で blog_id などを直接した記述は修正しておく（MT4上とMT5上とでblog_idはおそらく異なってくるので）
6. 移行先ブログで、現行ブログと同じようにカテゴリとフォルダを設定する
7. 現行サイトから画像などのデータを一旦ダウンロードし、移行先ブログのフォルダ内にアップロードする
   1. 普通にアイテムとして登録されている画像を格納しているフォルダだけでなく、WindowsLiveWriter を使って画像をアップロードすると作られるフォルダなども忘れずに移行する
8. 特殊な設定ファイルを一旦ダウンロードし、移行先ブログのフォルダ内にアップロードする
   1. 例） .htaccessやga.php(GoogleAnalytics) など
9. ブログ全体を再構築して、ただしく表示されることを確認する
10. 現行ブログを、フォルダ・URL指定を変更して再構築しておく
    1. この時点で現行ブログ自体のデータやMT4上設定をすべて削除してもいいのだろうが、念のために残しておく
11. 現行ブログの（それまでの）URLに対応するフォルダをフォルダごと削除する
12. 移行先ブログのURL指定をいま削除したフォルダの名前（＝これまでのURL）に変更して再構築する

以上になります。

この方法の欠点は、ウェブページが移行できてないこと（今回はもともとなかったので問題なし）、アイテムとしての情報が残らないことくらいでしょうか。

また、MT5 の管理画面には「検索/置換」機能があり、移行前後でテンプレートやブログ記事内の特定の記述を一気に変更＝置換したい時などに非常に便利だと思われます。

ご参考までに。