Ruby会議2009：Ruby, Railsによる「ケータイ」ポータルの作り方

Ruby会議 2009

Ruby, Railsによる
「ケータイ」
ポータルの作り方！
ニフティ株式会社成田智也 / 浜中慶

自己紹介
✦成田智也 / 浜中慶
✦ @nifty の Portal/CGM系サービスの開発

✦ @nifty の Portal/CGM系基盤の開発/運用

✦ （時々）実験的なサービスの企画/開発
✦ @nifty TimeLine / @nifty旅行日和

✦ @niftyのモバイル系サービス/基盤の開発/
運用

アジェンダ
✦ @niftyとRuby/Rails（これまで）
✦ ケータイサイトとその特徴

✦ ニフティでのケータイポータルの作り方

✦ ケータイポータル（集合体）の要件
✦ 現状とこれから

今日触れないこと
✦ 具体的なモバイル実装に関わる話
✦ Ruby/Railsのコード

✦ 周辺ミドルウェア/ライブラリの話

✦ Android / iPhoneに特化した話
✦ 所謂「ケータイ」サイト

2003年
✦ Ruby大好きエンジニアがニフティ入社

✦ Rubyいいよと周りに薦める

2007年

✦ @niftyでRuby, Rails製サービスが作られる

✦ β版サービス２サービス

✦ ニフティのサービス基盤として、向いてるかも。

✦ でも、まだLabs案件のみでの採用にとどまる...

200８年

✦ Rails製ケータイ向けCGMサービスを開始！

✦ 社内のインフラを徐々に整えはじめる!

✦ RailsPluginのOSS公開をやってみる!

その他

✦ サービス以外にもいくつかの活動

サービスだけじゃない
✦ 2007∼2009 Ruby会議スポンサー

✦ 福岡Rubyビジネス拠点推進会議顧問企業

サービスだけじゃない
✦ 慶応義塾大学寄付講座にてRuby利用（2007∼）
✦ 寄付講座は他にも、青山学院／上智大学でも実施

Ruby, Railsによる
「ケータイ」
ポータルの作り方とは

最近の@nifty
✦ ケータイサイトを結構やってる

４０サイト強

ケータイサイトの特徴
✦仕様変更当たり前
✦機種依存当たり前
✦ターゲット層と使われ方
✦スピード勝負

仕様変更当たり前
✦ キャリア「xxxサービス、はじめます」

✦ メーカー「端末にxx機能を追加します」

✦ ユーザー「もっと新しい物を！」

要件は収まらない（追加され続ける）ので、
キャッチアップ→作りつづける

機種依存当たり前
✦ 端末によって、
✦ 画面サイズが違う

✦ サポートする機能が違う

✦ 些細な挙動が違う

機種ごとの細やかな対応が必要になり、
新機種の対応内容も反映する必要がある

ターゲット層と使われ方
✦ 年齢：若年層あり（月5２5円払える）

✦ 時間：日中いつでも（手元にある）

✦ 使われ方も特徴的：

✦ メール/メルマガ重要

✦ 簡略操作（空メール/QRコード/UID）

ライフスタイルにあった利用
→システムもライフスタイルを追う必要

スピード勝負
✦ 簡単に作れる

✦ サイトの単位やデザインコスト

✦ 大手ベンダーの本格参入がされていない？

✦ 投資規模の小さなサイトが大多数？

✦ 無茶するベンダーが多い?

✦ 「動けばよい」も時には通る？

スピード感が求められる

ケータイサイトの特徴

✦ 仕様変更当たり前
✦ 機種依存当たり前

✦ ターゲット層と使われ方

✦ スピード勝負

@niftyの解（検証中）

Rubyで！

ところで
Q. Ruby on Railsにて構築されている、
国内の大規模モバイルサイト教えて。

A. あんまない（知られていない）

Rubyな理由
✦ 過去の実績／積み上げ
✦ トライアル／サービス経験
✦ 迅速なリリースサイクルが可能
✦ リリース後の改修しやすさ重要
✦ ソースコードが標準化しやすい

ニフティでの
ケータイポータル
の作り方!

@niftyケータイポータルの要件
✦ 量産が必須要件

✦ サービス単位の開発量は極力少なく

✦ サービス単位の運用量も極力少なく

✦ 継続的なエンハンスが必須

✦ メンバーの入れ替わりにも柔軟に対応

✦ 追加になったメンバーにもすぐに開発に入って
もらえるように

垂直統合型開発スタイル
メールメール
画像加工画像加工
レコメンドレコメンド

Webサービス Webサービス
個々のサービスで各種機能を開発

垂直統合型開発スタイル
✦ メリット
✦ 使いたいものを好きに使える

✦ デメリット

✦ 個々のサービス開発量が増える
✦ 各サービスのAPLサーバでImage
Magickや、postﬁxなどを保守する必要
がある

水平分業型開発スタイル

各サービスではAPIを叩くだけ

メール画像加工レコメンド
APIで機能を提供

水平分業型開発スタイル
✦ メリット
✦ メール受信/送信、画像加工処理を他シス
テムに移譲できる
✦ 個々のサービス開発量を削減できる
✦ デメリット

✦ サービスは委譲した側のシステムの制約を
受ける

現状
✦垂直統合型開発スタイル
✦ 各言語でフルスクラッチ（垂直統合）

✦ PHP, Java, Perl, Ruby....
✦ ミドルウェア構成もバラバラ

✦ 運用が大変...

これから（検討中）
✦水平分業＋柔軟性
✦基本はRuby/Rails
✦サービスとしてコアな箇所は、
一部垂直統合（独自開発）も

ケータイサービス
✦Ruby+Rails
✦jpmobile
✦社内Railsプラグイン
✦認証/メール/管理画面など

✦ﬁremobilesumilator / ssb

プロジェクト管理
✦ @niftyProject
✦ ruby製tracファーム（redmine化検討中）

✦ 開発規約の策定

✦ @nifty Rubyコーディング規約
✦ shugo maeda作のカスタマイズ版

✦ @nifty Railsセキュリティ規約

API：画像変換

✦ 端末にあった画像を作る
✦ P05AならWQVGAサイズへ変換
✦ いい感じの切り取り機能

API：汎用メール投稿
✦ 汎用モブログ受付君
✦ メール投稿（日記、メアド確定）

✦ 受け付けたメールを中継
✦ csv/tsv/yaml

✦ HTTPで中継（規定のREST仕様）

メールサーバの保守不要、導入が容易に

モバイル向けブラウザ

✦ ssbカスタマイズ（予定）
✦ シュミレーターの使い方の共有は無理

✦ 安全な携帯端末IDを付与

✦ ユーザデータなどの保護のため

まとめ！
✦ ケータイサービスやってる
✦ ポータル量産屋

✦ Ruby/Railsでやっていこうとしている
✦ ケータイサービス

✦ 共通機能も（水平分業型で）

ニフティでは一緒に
Ruby,Railsでサービス開発を
する仲間を募集しています！

ご清聴ありがとうございました!

<narita.tomoya@nifty.co.jp>
<hamanaka.kei@nifty.co.jp>

Ruby会議2009：Ruby, Railsによる「ケータイ」ポータルの作り方

Ruby会議2009：Ruby, Railsによる「ケータイ」ポータルの作り方

More Related Content

Viewers also liked

Similar to Ruby会議2009：Ruby, Railsによる「ケータイ」ポータルの作り方

Recently uploaded

Ruby会議2009：Ruby, Railsによる「ケータイ」ポータルの作り方