「これでMS Office（特にExcel）が使えればいいのに…」

はい、私もその通りです。で、それにトライした多くの方々がブログなどでその苦労を書かれてますね。類似のアプリを使ったり（QuickOfficeProだったりDocuments to GoだったりAppleのNumbersやKeynoteだったり）、Googleドキュメントに手を出したり…。

しかしどの方法もOfficeとの互換性に多かれ少なかれ課題があることに変わりはありません。なかには、Windowsパソコンにリモート（LogMeInかな）でログインしてみたりする強者もいましたが、これはこれでかなりスキルや設備のある人じゃないと無理ですし。

うーん、やっぱり無理なのか、MSがiPad用Officeを出すまで待たねばアカンのか…と思っていたのですが、ひょんなことから解決策を見つけました。

昨年辺りから、MSは「Office365」と称してOffice機能を含めたクラウド形式のグループウェアを推進しようとしています。本来は有料のこのサービスですが、同社のクラウドサービスであるSkyDriveのユーザーには、このOffice機能（Office Web Apps）がクラウドサービスとして提供されています。しかも無料！

要は、インターネットにつながっていればブラウザのなかでOfficeが動く、というものですね。…ということは、そうです、iPad（のSafariのなか）でもOfficeが動くのです！

「これか、これなのか！」と思って試してみたところ、まさに「これ」でした！

画面は、こんな感じです。

互換性に関しても、普通のOfficeと100%完全互換、というわけではなさそうですが、他社アプリなどに比べれば、なんといっても本家MS自身のサービスですから、その度合いは比べ物になりません。互換性については以下のページに記載がまとめてありました。

• ブラウザーと Excel でのブックの使用の相違点

ただし、VBA周りは弱そうですね。このあたりは、一口に「Excel」と言っても、Excelのどの機能を必要としているかによって、どの代替方法が適切かは変わってくるので、自分にある方法を選べばいい、と割り切ったほうがいいでしょう。私のとってはこのOffice Web Appsはかなり有効です。

また、クラウドサービスですから、売切のアプリよりも今後の機能強化も期待できそうですし。

それと、もちろんネット回線は必須です（このへん、ウェブのオフライン機能が充実していけば、ネット回線はゆくゆくは必須ではなくなっていくのかな？）。Wi-Fi環境なら快適に動きますし、ためしにServersManの格安SIM（500円/月）を入れたWi-Fiルーターでも、若干もっさりするけどちゃんと動きました。

これで、制限付きとは言え「Excel入りのiPad」を手に入れたことになりました。しばらくはこれを使っていこうと思います。

「Excel入りのiPad」に関心のある方は、一度試してみても損はないと思います。

2006年からケニアのナイロビに新聞記者として駐在した英国人の著者（アストン・ヴィラのサポーター）が、紛争や貧困といったアフリカの暗い話題以外の記事を書こうとして、各国の政治や社会の問題を、サッカーの視点（その国の代表チームだけでなくリーグ戦や街角でのサッカーも）から描くことはできないか、として各国を回って取材したものです。

10の章があり、一章ごとに1 〜2カ国を取り上げ、その国に赴いてサッカー関係者などにインタビューを重ねたり実際にサッカー観戦しています。外国人による取材が制限される国や地域ではその苦労ぶりも垣間見れます。

近年のその国の歴史を振り返ることで社会概要をとらえ、そこから何がその国の問題なのかも提示します。そのなかでは、政治や選挙のためにサッカーが文字通り利用される場面もあれば、サッカーこそが唯一の希望であるかのような国もあります。一口に「アフリカ」といっても、そのどれもに独自の歴史や社会を持つ人々が暮らしており、取り上げられている国も、章順に、エジプト、スーダンとチャド、ソマリア、ケニア、ルワンダとコンゴ民主共和国、ナイジェリア、コートジヴォワール、シエラレオネとリベリア、ジンバブエ、そして南アフリカ、と多種多様です。

例えば、コートジヴォワールにとってのドログバ選手は、単なる優秀な一サッカー選手ではなく、おそらく敗戦後や高度経済成長時の日本にとっての美空ひばりや長嶋茂雄といったアイコンのような存在なのでしょう。しかし、この本ではそうした有名人ばかりではなく、普通の市井の人々がサッカーにどう関わって暮らしているのか、も描かれています。

オーガナイズが行き届いたJリーグを見慣れた者にとっては、アフリカ各国のサッカーを取り巻く混沌さを読むと、まるで熱病にかかったかのように頭がクラクラして妙に息苦しくなってきます。この辺りは著者と訳者による記述の妙、といっていいでしょう。

それぞれの章自体は短編といってよく、その読後感は章によってそれぞれですが、個人的にはソマリアが好みでした。

残念なのは、取材期間が2006年から2010年初頭となっているので、アフリカ初開催となった南アフリカワールドカップのことが入っていないことと、やはりもう少し章ごとにボリュームが欲しかったところでしょうか。

もちろん、実社会のなかでサッカーによって変えることができる範囲など、たかが知れているのかもしれません。しかし、サッカーならばできることもある。多くの人々を集め、一つのことに向かって歓喜できること。そうしたことが、社会を少しでも良い方向に向けるために役立つのであれば、サッカーも捨てたものではないのかもしれません。

ただ、そうした希望をあっさりと打ち壊すのに十分なほど、今のアフリカ各国がいまだ多くの社会的課題を抱えていることもまた真実で、それを改めて教えてくれる一冊です。

自団体の支援者データに対して、もっと分析をして効果的な広報や支援者対応ができるのではないか、そのためには「支援者には多分こういう人が多いはず」といった思い込みでなく、きちんとデータ分析をした上で取り組みたい、という考えから手に取りました。もちろん、このレベルよりももっと基礎的な統計的基礎を踏まえてでないと、ということはわかってますワカッテマス。

ちまたで聞くようになった「ビッグデータ」というものについて、わかりやすく書いてくれています。いくつかキーとなる考え方をメモしておきます。

ビッグデータの特徴

データを取り扱う仕組みはこれまでにもあった。それとビッグデータは何が違うのか。

• Volume：データ量が極端に多い
• Variety：多様なデータ、正規化されていない（既存のRDBに入れにくい）データ
• Velocity：発生頻度や更新頻度が極端に速い

ビッグデータの活用パターン分類

ビッグデータの活用レベル

以下の順で一歩ずつ進めていく必要がある、と。

過去／現在の把握
　↓
パターンの発見
　↓
予測
　↓
最適化

活用のための戦略フレームワーク

これらを活かすために

読むほどになるほどなるほど、という感じでした。なんとなく出来そうだなとイメージできたのは、【１】個別最適・バッチ型（コア・社内としての支援者データに対して、支援者への個別アプローチ、そのための過去の把握〜パターンの発見）、【２】全体最適・バッチ型（サイト改善）、の２つでしょうか。

次は、統計の基礎の本を読むのと同時に、前に読んだ『集合知プログラミング』もちょっと読みなおしてみようと思います。

少し前にNHK『100分で名著』という番組でこの本を取り上げており、そこでは「震災後、被災地でこの本が多く読まれている」というかたちで紹介されていました。

恥ずかしながらいままで読んだことがなかったので、これを機会に読んでみました。太平洋戦争での敗戦後、多くの方が読んで励まされたというこの本が、いま震災被災地で読まれている、というのはどういうことなのか。

結果、「なぜもっと早く読まなかったのだオレは」本の今年第一号となりました。

本の内容自体はさまざまなところで紹介されていますし、たとえ僕が本書のなかで「ここが核心だ」と思った部分をここに引用したとしても、その前後の過程を踏まえてでないと、おそらく正確に理解・把握することは難しいように思えます。なので、ぜひご自身で読んでみてください。後悔はしないでしょう。もしかしたら、つらい時に読んだほうが効くかも。

世の中と自分の人生とに絶望しかかっていて「この先どうやって生きていけばいいのか」という人に対して、「人生を生きること」をどう捉えればいいのか、というヒントが示されています。ただ、「世の中にはこんなに過酷な状況の人がいるんだから、オレなんかが泣き事を言ってはいけない」というような「下には下がいるのだから我慢しろ」的な発想ではないのでご安心を。

そして、震災被災地で読まれているということは、「そのようにして考えざるを得ない」ほどまでに追い詰められた人たちが今もまだ多くいる、ということであると思うので、そのことはきちんと覚えておかなければならないことでしょう。でも、別にそれほどでなくても、将来にむけて不安を持っている人にとっても、今後を考えるヒントにはなるのではないでしょうか。うーん、でも若い人にはどうかなー…

もちろん、この本を読んだからといって、その人の人生が楽になる、ということはないでしょう（そんなん逆にコワい）。しかし、ちょっとは楽になるかもしれない、自分の周りにあった夜や霧が晴れるかもしれない、そんな本です。

2013年の年明けから、JVCウェブサイトの個別ページで表示していたtwitterトラックバックが表示されなくなりまして、ちょっと時間ができたので調べたところ、表示に利用していたjQueryのプラグイン（Twitter Trackbacks Widget – A jQuery Plugin）内で利用していたTOPSYのAPIの制限が適用されたため（01/08/2013の欄）でした。

とりあえず、TOPSYでAPI KEYを取得してそれをプラグインに埋め込んだので表示は再開されましたが、これは30日間のフリートライアルで、それ以降は有料の商用アカウントに移行するかどうかしなければならないので問い合わせてね的な感じ。

さて、どうしますかねぇ…

Eclipse MarketplaceからGitHub Mylyn Connectorをインストール。

File->Import  の画面でGitHub Task Repositoriesを選択。GitHubのユーザーIDとパスワードを入力。対象となるリポジトリを選択。エラーが出て、タイトル表記が空欄の選択肢がGitHub上のリポジトリの数だけ出てきたが、チェックボックスは押せて選択できる。すると、Eclipse上のTask Repositoriesのウィンドウで、該当のリポジトリが表示される。

Eclipse上のTask ListウィンドウのNewTaskのアイコンから、(Local)ではなくて”(GitHubリポジトリ）issues”を選択すると、タスクの関連情報を入力するウィンドウが作成されるので、タイトルやDescriptionを記入してsubmitボタンを押す。これでTask Listウィンドウに新しいタスクが作成された。ただ、タスクの左側に表示される◯印は、白（deactivate）のまま。タスクのステータスはopen。

この時点で、GitHubの管理画面をみると、issueが作成されてた！よしよし。

そしてEclipse上に戻って、タスクの◯印を紫に（activate）して、いくつかのファイルを更新してみると、Package ExplorerでのFocus on Active Taskも機能する。

しかし、作業が終わったものとしてタスクのウィンドウでステータスをcloseにしてsubmitボタンを押しても、ステータスが更新されない。もちろんGitHub側のissueもそのまま。なぜ？？

試しに、こちらの記事を参考に、GitHubとして変更をコミットする際に、コミットコメントのなかに”fixed #1″と記入してコミットしてみた。その後push。これでGitHub側にコミットは反映されて、issueのステータスもclosedに変わった。ここでEclipseのタスクのウィンドウのSynchronize Incoming Changesボタンを押すと、タスクがclosedに変化した。

しかし、GitHub上のコミットとタスクとで、完全にタイミングが連動させる必要はないはず。小さなタスクごとにコミットしてたらキリがないし。なので、GitHub側からissueをcloseにしてみると、それがMylynのタスク側にも反映された。

すぐに原因がわからないので、しばらくは

• タスク作成（オープン）：Mylyn側
• タスククローズ：GitHub側

という運用で使っていこう。うーむ、だれか詳しい方、原因を教えて下さい。

もろもろをだいぶ忘れていたので一から環境準備をやり直した際の手順をそのまま記しておく。各種環境も更新されたいたので以下にまとめておく。

• GAE/P SDK：1.6.5
• Python：2.7
• Django：1.2.5

1.まずEclipse上でGAEプロジェクトを作成

Eclipse上で、File -> New -> Others で、PyDev -> PyDev Google App Engine Project を選択。Project nameを指定する画面で、Grammar Versionは2.7を選択。Interpreterでも、python2.7を選択。Google App Engine Directory を選択する画面では、dev_appserver.py, appcfg.pyがある場所とうことで、/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine を選択。するとたくさんlibを選ぶ画面が出てくるので、ここで lib/django_1_2 も一応選択しておく。これでprojectはできた。

作成したprojectのpropertiesも見ておく。ResourceのText file encodingはUTF-8にしておく。

次に、お約束で、srcフォルダを作っておき、各ソースはこの下に作ることにする。

2.Djangoを入れてみて動かす

さて、次にGAEでDjangoを動かせるようにする。関連するドキュメントは以下のとおり。

• google-app-engine-django ：本文最初にあるようにもうout of date。ただし、Helper自体のダウンロードはここから行う。
• Django 1.2 on Google App Engine：上のoutotfdateの記事を参考に、Django1.2に対応させたもの。Django1.2自体のzipアーカイブを作る形式になっている。
• Using the Google App Engine Helper for Django（日本語ページ）：なので現在の基本はここ。
• Third-party Libraries in Python 2.7#Django：本家ドキュメントの最新部分。ただし、上の記事との差分のみ。
• Google App EngineでDjango1.2を動かす1：HelperのダウンロードからEclipseの画面を貼り付けながら日本語でやってくれている。とてもありがたい。ちょっと手順は逆になったが、これを参考にする。

現在のSDK1.6.5の時点では、もうDjango1.2自体はSDK内に入ってるのだから、それ自体のzipアーカイブなどをわざわざ別途用意する必要はないはず。ただし、Helperはダウンロードしてproject内に保持する、ということかな。

Helperをここからダウンロードする。現時点ではr117。これを、Eclipse上でsrcフォルダにimportする。ArchiveFileを選択して、いまダウンロードしたzipファイルを選択。select all してfinish。これで、srcフォルダ内にappengine_helper_for_djangoフォルダ以下が解凍された。その中のappengine_djangoフォルダやファイルをsrcフォルダ直下に移動した。これで、srcフォルダとappengine_djangoフォルダのアイコンがパッケージのもの（？）に変更された。で、中見がカラになったappengine_helper_for_djangoフォルダ自体は削除。

解凍されてきたapp.yaml内の記述を、今回の環境にあわせるために以下のように簡単に訂正。

application：自分のアプリケーション名
runtime: python27
threadsafe: true
libraries:
- name: django
  version: "1.2"

ここで、GAELauncherを起動して、File->Add Existing Applicationでprojectのsrcフォルダを選択し、ポートを8081とかに設定。そしてRunボタンを押すと、なんと動いた模様。さっそくブラウザで見てみると、

Fatal error when loading application configuration:
Invalid object:
threadsafe cannot be enabled with CGI handler: main.py

とのことなので、app.yamlのthreadsafeをfalseにすると、It worked! の画面が表示された。

なお、この時点でGAELauncherのログには、

The rdbms API is not available because the MySQLdb library could not be loaded.
Could not initialize images API; you are likely missing the Python "PIL" module. ImportError: No module named _imaging

の2つのワーニングが出てる。まぁあとにしよう。

3.そのままでデプロイしてみる

ではこれをデプロイ（本番環境にアップロード）してみる。GAELauncherのDeployボタンを押すだけで、デプロイは成功した。しかし本番URLでアクセスしてみたら、でかでかと

Error: Server Error

と出た。Dashboard（本番環境の管理画面）のログを見てみると、

File "/（本番URL）/appengine_django/__init__.py", line 152, in LoadDjango
 from google.appengine.dist import use_library
 ImportError: No module named dist

とのこと。これは「distというモジュールのインポートに失敗した」ということだろう。いろいろ調べたら、公式ドキュメントのなかに以下のページが見つかった。

What’s New in Python 2.7 （の途中）

The google.appengine.dist package has been removed, so methods like use_library() 
and webapp_django_version() are no longer available.

…え！？　distパッケージは（Python2.7で）削除された？　でもローカルのSDKでは動いてるよ？　しかもこのパッケージを呼び出してるのはHelperのなかからだけど…？　はっ、もしかして、「Helperは、”Django1.2″には対応しているが、”Python2.7″には対応してない（GAE本番環境のPython2.7では使えない）」ということか？outofdateってそういう意味なの？ってことはもしかして、全部やり直し？　ガーン…orz

4. さてどうするか。

…気を取り直して、今後の方針として、以下の2つが考えられるかな。

1. Python2.5に戻して、Helperを使ってやる
2. Python2.7のままで、Helper以外の方法を使ってDjangoを入れる

どっちかといえば、2が可能なら2のほうがいいな。言語のバージョンはなるべく新しいものに沿ったほうがなにかとうれしいものなので。よし、再調査開始！

5.（あらためて）Djangoを入れてみて動かす

さて調べてみたら、以下の記事が見つかった。

• GAE 1.6+Django 1.2
• Using Django-1.2 on Google App Engine with Python-2.7 runtime

どちらもHelperは使用してない様子。Django自体になれてないのでどうにも飲み込みが遅いが、後者は、ローカル環境にDjangoをインストールして、そのユーティリティであるdjango-admin.pyというやつを使ってプロジェクトを（おそらく雛形含めて）作成している。でも、前者は一から手で書いてる様子。ここでは前者を参考にして、下記のファイルを手で作成・記述した。一部は、Helperから作られた記述も取り入れている。

app.yaml

application: (アプリケーション名)
version: 1
runtime: python27
api_version: 1
threadsafe: false
handlers:
- url: /.*
  script: main.py
libraries:
- name: django
  version: "1.2"
env_variables:
  DJANGO_SETTINGS_MODULE: 'settings'

main.py

import os
def main():
    import django.core.handlers.wsgi
    # Google App Engine imports.
    from google.appengine.ext.webapp import util
    app = django.core.handlers.wsgi.WSGIHandler()
    util.run_wsgi_app(app)

settings.py

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
)
TEMPLATE_LOADERS = (
    'django.template.loaders.filesystem.load_template_source',
    'django.template.loaders.app_directories.load_template_source',
#     'django.template.loaders.eggs.load_template_source',
)
TEMPLATE_CONTEXT_PROCESSORS = (
#   'django.core.context_processors.auth',
    'django.core.context_processors.debug',
    'django.core.context_processors.i18n',
#    'django.core.context_processors.media',  # 0.97 only.
#    'django.core.context_processors.request',
)
INSTALLED_APPS = (
    'testapp'
)
ROOT_URLCONF = 'urls'
import os
ROOT_PATH = os.path.dirname(__file__)
TEMPLATE_DIRS = (
    ROOT_PATH + '/templates',
)

urls.py

from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^testapp/', 'testapp.views.home')
# Uncomment this for admin:
#     (r'^admin/', include('django.contrib.admin.urls')),
)

これで、srcフォルダのとなりにtestappフォルダを作ってHelloWorldをtemplates/testappフォルダ内のテンプレートを使って表示させるサンプルを作ってみたところ、動いた！ついでにDjangoのバージョンも django.VERSION で表示させてみたら、1.2.5.final.0と表示された。

…なんだ、もうHelperは必要なく、あっさり動くんじゃないか。

6.（あたらめて）そのままでデプロイしてみる

さて、肝心なのはこの次だが、deployしてみたところ、あっさり動いた。django.VERSIONもSDKと同じく1.2.5.final.0と表示された。Yes!!

7.これをgithubで管理させる

さて、難関は突破したので、あとは勢いで。

Eclipse上でGitを使うためのプラグインであるEGitのインストールや、github上でのSSHキーの登録はすでにこちらの記事を書いた時にしているので、それはクリアしたものとして、このプロジェクトをgithubで管理させてみる。

1. github上でリポジトリを作成。
2. Eclipse上のプロジェクトの右メニューからTeam->Share Project を選択し、次の画面でGitを選択。次の画面で、Use or create repository in parent folder of project を選択し、Create Repositoryボタンを押してfinish。
3. 念のため、この時点で全ファイルを一度コミットしとく。
4. 今度は、プロジェクトの右メニューからTeam->Remote->Push を選択し、Destination Git Repository画面がでる。各項目の設定は以下のとおり。
   1. URI：ssh://git@github.com:22/（アカウント名）/（リポジトリ名）.git
   2. Host：github.com
   3. Repository path：（アカウント名）/（リポジトリ名）.git
   4. Protcol：ssh
   5. Port：22
   6. User：git
   7. Password：空欄
   8. Store in Secure Store：チェックする
   9. nextボタン
5. SSHパスフレーズの再入力と、githubのサイトに訪れての確認を促されたので言われたとおりにする。
6. 次にでるPush Ref Specifications画面で、Source refでmaster[branch]を選択し、Add All Branch Specボタンを押して、next。次の画面でfinish。

これでPushまで完了。github側でいままで作ったソースがリポジトリに格納されていることが確認できた。

ふ〜、ここまで長かったが、この記事はここまで。

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

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章もこれで終わりです。ずいぶん長くなったので、続きは別エントリーにします。できれば明日中には更新します。