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

例えばこんな入力から、

 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が使えるようになっていたので、これも使います。

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