はじめに

昨年から日本でもFacebookユーザーが爆発的に増加しています。最近のWebアプリの多くはFacebookとの何らかの連携機能を持っていて、連携機能を持っていないものを探すほうが難しいかもしれません。

Facebook APIには多くの機能があるのですが、今回はその1つであるFacebook Query Language（以下FQL）について説明します。

なお本記事は、読者に以下の前提知識がある事を想定しています。

• Facebookの基本的な仕組み
• Facebookアプリ、Graph APIの基本的な仕組み
• Facebook SDKを使える程度のプログラミング知識

またテスト用のFacebookアプリをあらかじめ作成しておき、開発環境にFacebook SDKをダウンロードしておくとよいと思います（言語は問いません）。

はじめに

Retty株式会社の鹿島です。前回は、最近のWebサービスでよく使われている外部のAPIおよびサービス停止に致命的な影響を与えかねないrate limitについて説明しました。またrate limitの超過を防ぐための「キャッシュ」という方法についても説明しました。

具体例として、位置情報SNSサービスであるfoursquareのAPIを取り上げ、その結果をキャッシュする仕組みの基本的な設計を説明しました。ポイントとしては、以下の通りです。

• lat(=latitude=緯度)、lng(=longitude=経度)、検索キーワードの組み合わせをキャッシュのキーとする
• APIから返されるJSONをそのままキャッシュする
• キャッシュされたデータからlat, lngを用いて検索する際には、lat, lngにある程度の幅を持たせて検索する

今回は、MySQLで位置情報を扱うためのMySQL Spatial Extensionsについて説明した後、結果をキャッシュするためのテーブル、必要な関数の定義を行い、最後にテーブルに格納された位置情報を検索する方法について説明します。

はじめに

はじめまして。Retty株式会社の鹿島と申します。今回からこのblogに記事を書かせていただくことになりました。今後、読者の皆さんのご意見なども取り入れつつ、何か役に立つような内容を書いていければと思っていますので、よろしくお願いします。

この記事の内容ですが、我々が開発しているRettyというWebサービスでの実例を通じて、教科書にはあまり載っていないtips、落とし穴等を紹介したいと思います。対象読者として以下のような方を想定しています。

• Webサービス開発に興味がある人
• これからはじめようと思っている人（比較的初心者の方）

具体的には以下のような経験があることを前提としています。

• （言語を問わず）プログラミングの経験
• Facebook等のWebサービスの使用経験

このサイトに来ている方の大多数は、この前提をクリアしているだろうと思います。

Rettyのサービス概要

Rettyのサービスページ

まずは、我々が開発しているRettyというサービスについて少し紹介させて下さい。Rettyは「行ったお店を共有する、記録するソーシャルグルメサイト」です。具体的な機能は以下のようになります。

• 行ったお店のレビューを投稿する
• 「友達」や「嗜好の合う人」をフォローして、その人達の投稿をタイムライン（TL）上で閲覧する
• 行きたい店があった場合には、行きたいリストに追加する
• スマートフォンで、現在地付近の人気のお店、行きたいリストに追加したお店を検索する

サービスはWeb、iPhone、Androidのマルチプラットフォームで展開していますが、以下のように使い分けている方が多いようです。

• TLの閲覧やお店の行きたいリストへの追加 → Web
• 現在地付近のお店検索 → スマートフォン
• 投稿 → Web、スマートフォン両方

フリーソフトウェア/オープンソースソフトウェアの集合体としてのシステム

ePUBの作成にはいろいろな手法がありますが、制作を支えるシステムを構築する上で最も重視したのは、できる限り自動化し、手作業による調整を最小限にするということでした。そのため、このシステムでは原稿を常に最新マスターデータとしてそこから一方向にePUBを作成するバッチ型としており、たとえばSigilなどでePUBを後で細かに手直しする、といった手法は採用していません。

また、将来にわたって保守・改良が制作関係者自身の手でできるよう、中核部分をフリーソフトウェア/オープンソースソフトウェアで構成し、原稿の形式もオープンなものであることも当然の前提です。

さらに、訳者や編集者など制作にかかわる人たち（このシステムのユーザ）は、文章についてはプロフェッショナルであるもののソフトウェアについてはそうではありません（逆もまた真なり、ですね）。新しくツールを導入したことでそれに振り回されないように、ユーザ側から見て新しく導入するものを最小限にし、面倒な部分はできるだけシステムの内部に置くとともに、原稿の文法エラーチェックなどを自動化し、原稿更新に合わせて即座にePUBやHTMLのプレビューもできるようにする必要もありました。

こうした背景からできあがったのが、次の図に示すシステムです。

オライリー・ジャパンのePUBを制作しているシステム

このシステムで採用している技術やソフトウェアの概要をまとめてみます。

対象環境

この記事では、 Python 2.7.2 でソースコードを実行して確認しています。

コーディングスタイルについて

名前空間やスコープの前に、まずは基本的なコーディングスタイルについて軽くお話しします。

Python のコーディングスタイルというと、 PEP 8 – Style Guide for Python Code (日本語訳は こちら )が有名です。 これは、 Python でプログラムを書く上で守っておくとよいお作法について書かれており、 Python のコーディングスタイルとしてはデファクトスタンダードといえるでしょう。

この PEP8、例えば以下のようなことが書かれています。

• インデントは 4 スペースで
• タブとスペースを混ぜて使わない

といったような Python らしいインデントの話から

• 演算子の前後にスペースを入れる
• 代入演算子を縦にそろえるためスペースを入れることはしない
• モジュール・クラス・変数・関数などの名規則
• 推奨される例外処理方法

などの書き方に関することまで広範に及びます。

Python で開発をするのであれば一読しておくことをオススメします。 また、このスタイルを守ると多くの Pythonista にとって読みやすいソースコードになるのではないでしょうか。

今回は、前回取り上げたsquashfs,aufs,cloop,dm-snapshotの各機能を用いた、LiveCDに必要な機能を実現するための組合せを考えてみます。 なお、本記事はhttp://sourceforge.net/mailarchive/forum.php?thread_name=20986.1293537718%40jrobl&forum_name=aufs-usersを元にしています。

方式ごとの性能比較

ここまで、squashfs,aufs,cloop,dm-snapshotの各機能を簡単に紹介しました。次にLiveCDに必要な機能を実現するための組合せを考えてみます。組合せ要素には圧縮された読み取り専用下位レイヤ、書き込み可能上位レイヤ、両レイヤの結合方法の三種類がありますが、前述のようにdm-snapshotの場合にはファイルシステム種類に条件が加わるため、次のようになります（表1）。

古代の構成

一般的にLinux LiveCDではシステムをインストールした状態のファイルシステムを圧縮し、読み取り専用ファイルシステムイメージとして収納してあります。この際に用いられるのがsquashfsなどのファイルシステムですが、ここからそのままシステムを起動しても読み取り専用ですから、使用できない部分が生まれます。

圧縮の反対動作を指す言葉は伸長とも表現されますが、本記事では展開と表現します。

例えば、システムを起動すれば各種ログファイルや/var/wtmpファイルに対する書き込みが発生しますし、ファイルシステムをマウントすれば/etc/mtabというファイルも更新されます。デーモンが起動されればサービスに必要な各種ファイルなども作成されます。それぞれを一つづつ調査し、書き込みが発生しないように対処して行くことも不可能ではないかもしれませんが、もちろん手間がかかります。そもそもLinux（UNIX）システムは書き込み可能ファイルシステム上で動作することを前提としているのですから、この努力は有意義とは言えないでしょう。

かつてはシャドウディレクトリ方式で対応しようという時代もありました。シャドウディレクトリとはやや古い呼び方かもしれませんが、X.Org/XFree86以前のX11 Window Systemのビルドなどにも用いられていた（と思うけど、記憶に自信がなくなってきた ）形態です。例えば、ソースファイルが置かれたsrc/下でそのままビルドすると、他のアーキテクチャ用にビルドする際には全オブジェクトファイルを削除しなければなりません。そうすると、先のアーキテクチャ用のリビルド時にはまた初めからすべてをコンパイルしなければならず、この手間暇を節約するための方策として、obj/を別に用意し、全てのソースファイルのシンボリックリンクをobj/下に作成する方法が採られました。この形態がシャドウディレクトリで、ビルドされるオブジェクトファイルはobj/下に作成され、ソースファイルを書く場合にもディレクトリの差異を気にする必要もありません。lndir(1)を用いると、子ディレクトリ、孫ディレクトリも含んだシャドウディレクトリを作成できます。

大量のリクエストを捌くWebサイトを構築するには、さまざまなノウハウがあります。例えばオライリーの書籍『ハイパフォーマンスWebサイト』では、クライアントに配信するコンテンツを最適化することでパフォーマンスの向上を図っています。今回は、Pythonを使って月間10億を超える（！）リクエストを捌いている、株式会社クロスリスティングの方に、そのノウハウの一部を寄稿していただきました。
また、本記事の内容はPython Hack-a-thon 2010.07でのプレゼンテーションを元にしています

自己紹介

現在、私はクロスリスティングという会社で、広告配信システムとか、その周辺の新規商品関連の研究開発をやっています。メインのプログラミング言語はPythonです。自社でのシステム開発は基本的に全てPythonを使っています。自分は研究開発的なポジションですが、技術チームが開発しているプロダクションシステムもほぼ100% Pythonで開発されています。

「Pythonはバイトコードインタプリタのランタイムで動作するので、（JITを含めて）ネイティブコードにコンパイルする言語に比べて、実効速度の点で不利でありハイトラフィックなWebサービスの実装言語として向かないのではないか」という話を良く聞きます。今回は、Pythonで構築されているWeb広告配信サーバと、その周辺ツールについて、すこし紹介できればと思っています。