Contributors Postの最近の記事

Community Blogへご参加いただいている執筆者による投稿記事です。

ここ最近のWebサービスでは、Googleを始めとする他のサービスが提供するAPIを使用して、そのデータを活用するというのが当たり前になってきており、また、そのためのライブラリ等の基盤も整っています。今回はそうしたライブラリの使い方からちょっとだけ先に進んで、外部APIのアクセス数制限を回避するためのキャッシュについて説明します。

はじめに

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

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

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

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

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

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

Rettyのサービス概要

Rettyのサービスページ

Rettyのサービスページ

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

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

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

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

オライリー・ジャパンから先日発表されたプレスリリース「ePUBフォーマットによる電子書籍のラインナップを開始します」にあるとおり、弊社トップスタジオはオライリー・ジャパンとの共同事業として、ePUBフォーマットでの電子書籍の制作を開始しました。 トップスタジオではこのePUBフォーマット電子書籍の出版候補の選定、翻訳、編集、そしてePUB制作までに関わっています。本稿では、このePUBの制作プロセスを支えるシステムにフォーカスを当て、その仕組みについて紹介します。

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

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

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

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

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

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

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

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

プログラムのロジックを考え、実装を行う上で、変数の名前空間やスコープはとても重要です。 これらはロジックを組み立てる上での複雑さに直結し、ソースコードの読みやすさにダイレクトに関係してくるためです。 この記事では、私が Python で開発をする上で気をつけるようにしている名前空間やスコープに関するお話をします。

対象環境

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

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

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

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

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

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

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

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

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

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

今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。

git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。

git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性から各開発者ごとにブランチが 分散 しがちであったり、最新バージョンが把握しにくいといった不便を感じることがあります。

このツールを導入することで、git の長所を損なわずに、

  • 分散型バージョンコントロールシステムである git に集中型 (Subversion 等) の長所を取り入れることができる
  • チーム内でブランチモデルを共通化できる

などの利点を得ることが可能です。

分散型に対する集中型の長所は、

  • リポジトリが 1 つのため、管理が簡単
  • マスターが 1 つのため、最新バージョンが把握しやすい
  • コミットすべきリポジトリがわかりやすい。

と言われています。これは、リポジトリが 1 箇所にあることの長所であり、短所です。 git-flow では、中央と みなす リポジトリ origin を作成することで、この長所を取り入れています。

centr-decentr.png

Git ブランチモデル( A successful Git branching model より。Creative Commons BY-SA ライセンス)

git-flow のブランチモデルを要約すると、

origin には master, develop という 2 つの メインブランチ を保持します。

  • master: リリースブランチ。プロダクトとしてリリースするためのブランチ。リリースしたらタグ付けする。集中型でいう trunk、tag。
  • develop: 開発ブランチ。コードが安定し、リリース準備ができたら master へマージする。リリース前はこのブランチが最新バージョンとなる。

各開発者は master, develop の他に、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチという サポートブランチ を利用し分散開発します。このブランチは最終的には破棄されます。各ブランチの目的は

  • フィーチャーブランチ: 機能の追加。 develop から分岐し、 develop にマージする。
  • リリースブランチ: プロダクトリリースの準備。 機能の追加やマイナーなバグフィックスとは独立させることで、 リリース時に含めるコードを綺麗な状態に保つ(機能追加中で未使用のコードなどを含まないようにする)ことができる。 develop ブランチにリリース予定の機能やバグフィックスがほぼ反映した状態で develop から分岐する。 リリース準備が整ったら, master にマージし、タグをつける。次に develop にマージする。
  • ホットフィックスブランチ: リリース後のクリティカルなバグフィックスなど、 現在のプロダクトのバージョンに対する変更用。 master から分岐し、 master にマージし、タグをつける。次に develop にマージする。

となります。このサポートブランチにより、マージ、コミットすべきブランチを明確化することができます。

2008年にリリースされたPython 3。さまざまな機能が追加、更新されている中に私たち日本人にとっては嬉しい機能が追加されています。今回はその機能を提案・設計したご本人に解説をご寄稿いただきました。
また、本記事の内容はPython Hack-a-thon 2010.07でのプレゼンテーションを元にしています

Python 2.x までのオブジェクト文字列表現

Pythonを使ってプログラムを開発していると、デバッグ中などにこんな感じの文字列をよく目にします。

>>> "abc\tdef"
'abc\tdef'
>>> datetime.datetime.now()
datetime.datetime(2010, 7, 9, 13, 37, 49, 107000)

"abc\tdef"datetime.datetime.now()という式を評価した結果が、'abc\tdef'datetime.datetime(2010, 7, 9, 13, 37, 49, 107000)のように表示されています。このような、Pythonの値をデバッグ用に読みやすく整形した文字列を「オブジェクトの文字列表現」と言います。

アーカイブ