Contributors Postの最近の記事

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

Contributors Post

TestFlightとJenkinsを組み合わせたアプリの配布

|

前回はビルド設定とスキーマにより本番環境とテスト環境を数クリックで切り替えられる仕組みを説明しました。

今回はTestFlightによるアプリ配布と、Jenkinsを組み合わせてアプリ開発者以外でもアプリ配布ができるようになる仕組みの構築について説明します。

はじめに

背景と問題点

私がRettyで仕事を始めたとき、アプリを配布する仕組みは特になく、アプリの評価が必要になるたびに実機を借りてインストールを行い、評価をしていました。その後、会社のメンバーやインターンの数が増えてくるにしたがって、以下のような問題が出てきました。

  • 評価を行うメンバーの全端末にそれぞれインストールするのが煩雑になってきた
  • 開発者の数は増えたがiOS開発者は増えなかったため、インストール依頼の負荷がiOS開発者にかかるようになった
  • 開発者の増加にともない開発環境が増え、ビルド設定とスキーマでカバーしきれなくなっていた*1

このような問題を解決するため、Rettyでは以下のようなアプローチをとりました。

  • TestFlightのようなOver The Air(以下、OTA)のサービスを利用し、アプリを全端末や特定のグループに対して一斉配信するようにした
  • Jenkinsを導入し、アプリ開発者でなくても好きなタイミングでアプリを配布できるようにした
  • Jenkinsからシェルスクリプトを使って設定を自動的に書き換えて、ビルド設定とスキーマに設定されていない環境向けのアプリも作れるようにした

ここから、それぞれのアプローチについて詳しく説明します。

[*1] Rettyでは開発環境を1人につき1つづつ払い出しているため、2014.7.27現在では30弱の開発環境が存在しています

Contributors Post

iOS開発でのスキーマとビルド設定の活用

|

お待たせいたしました。久しぶりにRetty株式会社さんからご寄稿をいただきました。今回は、iOS開発での環境を切り変えるために便利な「スキーマとビルド設定」について、ご自身の体験を交えてご紹介いただいております。

ごあいさつ

はじめまして、Retty株式会社の櫻井と申します。今回からiOSの開発で得たノウハウなどをブログ記事に書かせていただくこととなりました。今後、読者の皆さんのご意見なども取り入れつつ、何か役に立つような記事を書いていきたいと思っていますので、よろしくお願いします。

記事の内容としては、弊社で開発しているRettyというグルメサービスの開発の実例を通じて、教科書にはあまり載っていないTIPS、落とし穴等を紹介したいと思います。対象読者として複数人のチームでiOSアプリ開発をされている方を想定しています。

はじめに

背景と問題点

サービスとして提供し続けるWebアプリケーションを作るとき、本番環境と開発環境を別々に作っておき、一般ユーザーからのアクセスは本番環境へ接続されるようにし、開発メンバーが開発するをときには開発環境にアクセスするようにするというのは一般的な手法です。

この手法は、WebアプリケーションだけでなくiOSアプリ開発においてもそのまま適用されており、iOSアプリ開発において本番環境と開発環境を用意している会社さんも多くあるでしょう(以下、iOSアプリという表記はアプリと省略します)。

私がRettyで仕事を始めたとき、本番環境が1つと開発環境が2つ、計3つのサーバ環境がありました。その当時、アプリをどの環境に対して接続するかは、ソースコード内の定数値を毎回書き換えて指定していたため、以下のような問題が起きていました。

  • 本番環境と開発環境の切り替えが煩雑になっていた
  • アプリの表示名が同じものになってしまっており、端末に入っているアプリが本番環境に接続されているのか開発環境に接続されているのかがひと目でわからなかった
  • 間違って開発環境の設定のままアプリのリリース申請をしそうになってしまった

このような問題はXcodeのスキーマとビルド設定によって解決することができます。

その他に、設定ファイルをsedなどのコマンドで該当行の内容を一括置換できるようなスクリプトを作成する手法が考えられますが、この手法は以下の点からあまり有用でないと考えます。

  • 現在のプロジェクト状態がどの環境に接続するものなのかは設定ファイルの状態を確認しないとわからない
  • XCodeのみで作業を完結できない(いちいちターミナルからコマンドを叩かないといけない)

Contributors Post

Webサービスにおける外部APIの使用(その3) - Facebook Query Language

|

最近はFacebookのユーザー、Facebookアプリの数が増えています。本記事では、はじめにFacebook APIについて簡単に説明した後、Facebookが持っている情報を効率的に取得するためのFacebook Query Language(FQL)について説明します。

はじめに

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

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

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

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

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

Contributors Post

Webサービスにおける外部APIの使用(その2) - MySQL Spatial Extensionsによる位置情報の検索

|

最近のWebサービスでは、外部APIを活用したものが非常に多くなっています。前回は外部APIのアクセス数制限を回避するためのキャッシュ、及び具体例として位置情報サービスのfoursquare APIの結果をキャッシュする仕組みを設計しました。今回は、MySQLに保存された位置情報データのキャッシュをMySQL Spatial Extensionsを使って検索する方法について説明します。

はじめに

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

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

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

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

Contributors Post

Webサービスにおける外部APIの使用(その1) - キャッシュ

|

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

はじめに

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

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

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

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

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

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

Rettyのサービス概要

Rettyのサービスページ

Rettyのサービスページ

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

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

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

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

Contributors Post

オライリー・ジャパンのePUBフォーマットを支える制作システム

|

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

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

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

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

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

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

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

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

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

Contributors Post

Python の名前空間とスコープ

|

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

対象環境

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

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

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

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

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

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

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

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

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

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

Contributors Post

git-flow によるブランチの管理

|

今回は分散バージョン管理システム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 にマージする。

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

Contributors Post

その1:ログ処理編-CDBを利用した簡易KVS

|

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

自己紹介

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

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

Contributors Post

Python 3 のオブジェクト文字列表現

|

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の値をデバッグ用に読みやすく整形した文字列を「オブジェクトの文字列表現」と言います。

アーカイブ