Web.Dev | Facebook の新しい OAuth 認可ダイアログ

Facebook、「アプリの許可」ダイアログを改善 - ITmedia ニュース

間もなくすべての Facebook アプリに適用される新しい OAuth 認可ダイアログ。
拡張パーミッションを OAuth の要求パーミッションに指定した場合、新しいダイアログではユーザーはそのパーミッションを外して OAuth 認可することができるようになる。

つまり、あるアプリがユーザーフィード(ウォール)の読み書き権限の認可を求めたとしても、ユーザーは読み込み権限だけ許可し、書き込み権限は許可しないということが可能になる。
これはアプリ側にとっては結構やっかいで、フィードの読み書き両方ができて初めてアプリ本来の機能を提供することができる場合に、どちらか一方だけ許可されても意味がない。要求したパーミッションに対しては All or Nothing であって欲しいのだ。

OAuth の仕様上、アプリが要求したパーミッション(スコープ)がすべて許可されたのか一部分だけ許可されたのかは分からない。Facebook では Graph API の /{uid}/permissions にアクセスすればユーザーのパーミッションを取得できるので、要求した全パーミッションが許可されたどうかをチェックすることはできる。

一般ユーザーにとっては認可ダイアログで[許可]ボタンを押せばアプリは使えると思って、一部のパーミッションを外してダイアログで[許可]ボタンを押すこともあるだろう。しかし、アプリではパーミッションが足りず、「もう一度認証してください」的なエラーを出さざるを得ないケースも・・・

ユーザーのプライバシーを尊重する仕様変更なのは分かるけど、開発者泣かせの変更だ。弱ったな。

Web.Dev | nginx で POST リクエストが 405

Facebook ページのコンテンツを提供する Web サーバに nginx を使おうとテストしていたら、nginx では POST リクエストで静的ファイルを返せない仕様であることが判明。POST に対するレスポンスが 405 not allowed になってしまう。
Facebook ページのキャンバスからは POST でリクエストが来るので、POST を捌けないことにはどうしようもない。

回避策として、このフォーラムを参考に

error_page 405 = $uri;

Python | Python library for Facebook Graph API

これまでストリッパーズの仕事で何度か Facebook の API を使ったサイトを作っていて、1年くらい前に作った Python ライブラリを使い回してた。
Facebook の Graph API 自体、シンプルな構造なので、ライブラリも別に使いにくいわけじゃなかったんだけど、あまり直感的ではなかった。巷にある Python 用の Facebook ライブラリを見ても、何か違うなあと思って、来月また Facebook と連携させるプロジェクトがあるのを機に大幅にライブラリを作り直してみた。ついでに PyPI にアップしてみた。
とりあえず今度のプロジェクトで最低限必要になりそうな API を実装した。まだドキュメントもないし、作り途中でテストも大してやってないけど。

今ある機能の簡単な使い方をまとめる。
まずは strippers.facebook.graphapi.FacebookGraphAPI インスタンスを生成するんだけど、以下の 3 つの方法がある。

(1) 外部サイトで OAuth 認可を取る場合

from strippers.facebook import graphapi

scopes = ['publish_stream', 'read_stream', 'email', 'user_photos']
redirect_uri = 'http://www.example.com/oauth/authorized'
auth_url = graphapi.get_auth_url(APP_ID, scopes, redirect_uri)
# この auth_url にリダイレクトさせて・・・あとは WEB+DB PRESS Vol.63 を読んで :-)

api = graphapi.initialze(APP_ID, APP_SECRET, auth_code, redirect_uri)

(2) Facebook JavaScript SDK を使ったページからのリクエストでは、クッキーにセットされた認証情報からアクセストークンを取得する。

from strippers.facebook import graphapi

# Django の view の場合
def execute(request):
    api = graphapi.initialze(APP_ID, APP_SECRET, request.COOKIES)

(3) 既にアクセストークンがある場合。

from strippers.facebook import graphapi

# データベースやセッションなどに保存したユーザーのアクセストークンを取得
access_token = get_access_token_from_somewhere()

api = graphapi.FacebookGraphAPI(access_token)

FacebookGraphAPI インスタンスができたら、あとは以下の例文のような感じで。認可されているスコープ(パーミッション)によっては使えない機能もある。
基本的には api.user() メソッドで取得する User オブジェクトを基点とする。
各グラフオブジェクトは Python の dictionary-like object になっている。フィールドデータは遅延ロードするようになっていて、例えば友達の User オブジェクトが id と name フィールドしか持っていない場合に、friend['gender'] にアクセスしたら、その時点で友達のフィールドデータをロードする。オシャレ。

もう 1 つのオシャレポイントは、メソッドによっては遅延ロードや通信回数を減らすため、内部的に Graph API ではなく FQL を使って Facebook に問いあわせしているところ。
FQL は api.fql_query() メソッドで実行できる。

api.access_token # アクセストークン

my = api.user('me') # 自分のユーザーオブジェクト
my = api.me # 上と同じ

my['name'] # 自分の名前
my.friend_count # 友達数

# 自分の友達リスト取得
friends = my.friends()

friend = friends[0]
friend.picture('large') # 友達のプロフィール画像URL(大きめサイズ)

# 自分のウォールに投稿 
my.post('投稿メッセージ', link='http://www.example.com', name='例', caption='キャプション')
# 友達のウォールに投稿
api.post(friend['id'], 'ハロー')

# 自分の最新 50 件の投稿を取得
for post in my.posts(50):
    post.get('message')

# アルバムを作成
album = my.create_album('新しいアルバムの名前')
# アルバムに写真をアップロード
photo = album.upload_photo(open('friends.jpg', 'rb'), '写真の説明文')
# その写真に友達をタグ付け
photo.tag(friends[0]['id'], x=123, y=345).tag(friends[1]['id'], x=234, y=345)

# アプリから友達にメール送信
api.rest_api.notifications_send_email(friend['id'], '件名', '本文')

しばらくは毎日のように機能追加やバグ修正のアップデートをしていくと思う。

Web.Dev | うざ「いいね」

今、facebookの袋とじページが熱い*ホームページを作る人のネタ帳

今日の社内ミーティングでもちょっと話題になったのだけど、Facebook で「いいね」押さないと見られない Facebook ページやアプリはうざいと。嫌いだと。

ユーザーがページの中を見て初めて好きかどうか、つまり「いいね」を押すかどうか判断するのが自然な流れなはずなのに、中を見るより先に「いいね」の評価を要求するのはおかしい。やり方がせこいと言うか、品がないと思う。

こんな風に思うユーザーが増えていくことになれば、「いいね」を要求することによって、逆にその Facebook ページへのユーザーの接触機会を減らしてしまうことになり、本末転倒なことになっていくだろう。

Facebook ページの評価指標として「いいね」数を競うような風潮もどうかと思うのだけど、先に「いいね」を押させるコンテンツの「いいね」数にどれだけの意味があるのか。

Web.Dev | iPad と Flash

2、3ヶ月前から家で iPad をよく使うようになった。それ以前は、PC の方が便利、iPad は何に使えばいいのか分からないと文句タラタラだったのだけど、最近は家であまりノート PC を使いたくなくなってきてて、Web ブラウズとメール閲覧、Facebook と twitter くらいなら iPad だけで済ますようになってきた。それ以外はたまにベッドで YouTube を見るくらいで、ほとんどアプリは使ってない。iPad で読書というのは、まぶしがり屋の僕には今後も難しそう。

こうして iPad でサイトを見るようになると、iPad が Flash に対応してないのはショボイよなと思う反面、なんでこのサイトは今時 Flash 使ってんのよ？と思ったりもする。
僕の場合は特に、テレビを観てて気になる CM が流れた後、もう一度観ようとその企業のページを開くことがあるんだけど、CM 動画のプレーヤーに Flash を使っているケースに出くわすことがしばしば。動画再生くらい HTML5 でやって欲しい。HTML5 に対応してないブラウザの場合に Flash で再生するライブラリとかあるんだから。それぞれの形式に動画をエンコードするのは面倒かも知れないけど。

あとトップページに Flash 使ってるサイト。中身のコンテンツは HTML ページで構成されているのを PC で見て知ってるんだけど、トップが Flash なためにその HTML ページに辿りつけないケース。こういうのはもったいないなぁと思う。

そんなことを考えつつ自分たちの仕事を振り返ると、、、Flash 全開だったりする。Flash じゃなければ表現できない、実現できないこともまだまだあるし、開発のしやすさから言えば Flash の方が圧倒的に上だし、クライアントが IE6 使ってたりして HTML5 どころじゃないなんてこともある。クロスブラウザで完全に動作させることを考えると、まだしばらくは Flash 優位な状況が続きそう。
でも、それ本当に Flash じゃなきゃできないのか、それだけの機能なら HTML5 + CSS3 でもクロスブラウザで実現可能(例えば先の動画再生みたいなやつ)じゃない？ってところはそろそろちゃんと考えていく必要がある。

同業ではない僕の同世代の友人も Web サイトを見るのは専ら iPhone を使って、滅多なことではわざわざ PC を起動することはないと言ってたりするし、そういう時代になってきてるのかも知れない。

Python | Django の便利機能

このブログの作り直しを Django を使って進めている。いろいろと実験を兼ねて、今までちゃんと使ったことなかった Django の機能を使ってみたり、HTML5 で書いてみたりしてる。

ブログの基本的なところは Django の Admin 機能を使ってすぐに出来た。
Movable Type のデータベースからこれまでのブログエントリーとコメントを取得して、新しいデータベースに突っ込み、古い URL にアクセスしたら新しい URL にリダイレクトする機能も実装できた。

エントリーへのコメント機能も Django 付属のコメントフレームワークを使うと簡単に実装できた。だが、このコメントフレームワークはカスタマイズがあまり柔軟に出来ず、もう少しソースを追ってみるけど、このまま使うか自前で実装するかはまだ分からない。
コメントフレームワークには、ハニーポットやタイムスタンプなどいくつか spam 対策が仕掛けられてて、なかなか面白い。

RSS/Atom フィードも Django 付属のフィードフレームワークを使えば簡単。すばらしいね、Django は。今まで使ったことなかったけど、便利機能がたくさん付属してた。

もうひとつ今まで知らなかった機能が、メッセージフレームワーク。「メッセージ」という名前から、シグナルやメッセージキュー的な機能だと思い込んでいたのだけど、Rails で言うところの flash 機能に該当するものだった。しかも、メッセージレベルという面白い概念も備わっている。Rails の flash が Django にはないのが不便だと思っていたけど、あったんだね。
これを無理矢理新しいブログで使うようにしてみたのだけど、メッセージが画面に表示されず嵌まっていたところ、render_to_response() 関数に RequestContext インスタンスを渡す必要があることがドキュメントをよく読んで分かった。
余談だけど、Django で不満なところはこの RequestContext だ。なぜこれをデフォルトの Context にしなかったのだろう。いちいち ReqestContext インスタンスを生成したり、指定したりしなければいけないのが面倒くさい。

ブログでは今のところ使っていないけれど、Django 開発版に新たに追加された面白いものが Cryptographic signing。これは簡単に言うと暗号化と復号の機能なんだけど、便利そうだと思ったのが、復号時に生成時点からの有効期間を指定できる点。「この URL には 24 時間以内にアクセスしてください」的な URL をデータベース要らずで簡単に実装できそう。

最後に Django 組み込みのものではないけれど、django_compressor がえらい便利。これは標準で組み込むべきアプリだと思った。
Rails 3.1 から CoffeeScript と sass がサポートされるようになって、その機能が羨ましかったので、Django 版を作るかと思っていたところ、すでにあった。しかも、CoffeeScript や sass だけではなく、汎用的にこういったコンパイラを設定できる。
コンパイル前の例えば scss ファイルといった、いわゆるソースファイルがドキュメントルート下に置かなければいけないことが少し気になったけど、見られてすごく困る類いのモノではないし、Web サーバで .scss へのアクセス制限を掛けるようにすればいいだけか。

Web.Dev | ステルスサブミット

ストリッパーズは来月、事務所を引っ越します。また駒沢だけど。いろいろとお金が掛かるので、引っ越し倒産するんじゃないかとちょっと不安な今日この頃。

さて、その引っ越し業者を選定するため、先日うちのスタッフが、複数の業者に一括して見積もり依頼できるサービスの依頼フォームに情報を入力していたところ、まだ送信ボタンを押していないのに、ある引っ越し業者から電話が掛かってきた。

そのスタッフは電話で「まだ送信ボタンを押してないんですけど」と伝えたところ、業者は「送信ボタン押してなくても送信されてくる場合があるんです」といったよく分からない怖い返答。
社内に盗聴器でも付いてるのでは、なんて話をしていたのだけど、技術的には Ajax 使えばフォーム入力内容を送信ボタン押下の有無に関係なく送ることは可能だ。でも、こういうことをやられるのは気分がいいものではないな。

Google Analytics のコンバージョンの機能では、例えば商品購入までのプロセスでどのページで離脱するユーザーが多いか分かるけど、それをさらに突き詰めていくと、購入フォームや申し込みフォームのどこまでどういう内容を入力して離脱したかといったデータを取るようになるのかも。

ステマが最近話題だけど、検索フォームの Suggestions 目的以上の、言わばフォームのステルスサブミットにも今後は気をつけないと。僕が知らないだけで、意外ともう一般化してるのかな。

Misc. | プロモーター先行

MUSIC PARTY - DISK GARAGE

ライブのチケットは、(1)ファンクラブ先行、(2)CD/DVD封入特典の先行、(3)アーティストのホームページ先行、(4)プロモーター先行、(5)ぴあ/e+/ローチケ等のプレイガイド先行、(6)プレイガイド一般発売と、一般発売に至るまでに先行販売(主に抽選販売)が何度もあり、一般発売ではわずかのチケットしか売られていないことも。一般的には上の順番で良い席が割り当てられる。

プロモーターっていうのは公演の主催者で、公演の企画制作・運営を行う会社。実際にどんな内容の仕事なのかは知らないのだけど、東京近郊の邦楽ライブイベントのプロモーターとしては、DISK GARAGE / HOT STUFF / SOGO TOKYO / FLIP SIDE / KYODO TOKYO の 5 社が思い付く。

プロモーター先行でチケットを取るには、各プロモーターで会員登録しなければないらないのだけど、上記 5 社の中で DISK GARAGE は MUSIC PARTY という有料会員を募集している。この MUSIC PARTY のメンバーになると、無料会員より先にチケットを入手するチャンスがある。

DISK GARAGE はグループ魂や安藤裕子などの僕が好きなアーティストを取り扱っているので、今年は思い切って有料会員に申し込んでみた。年会費 4,000円。特定のアーティストのファンクラブに入ってもこれくらいは取られるので、決して高くはないと思うけど、果たして会費を払った甲斐があったと来年も継続したくなるような成果を上げられるだろうか。