FJORD, LLC（合同会社フィヨルド）

こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp（kowabana.jp）のシステム構成や開発方法についても公開していこうと思います。

怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。

怖話.jpとは

スマホで17000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト（アプリではありません）です。詳しくは下記エントリーを参照してください。

スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC（合同会社フィヨルド）

7月16日にRubyKaigiに合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは１ヶ月立ってないまだまだのサイトです。開発期間は約１ヶ月ぐらいです。

サイト情報

（これAnalyticsを直接貼るのはどうやればいいんだろう？）

直近一ヶ月のPVは49,220です。特徴としては、平均滞在時間が4:58とちょっと長い。直帰率が55.37%とちょっと少ないという感じでしょうか？

サーバー構成

サーバー：さくらVPS512（月額980円）

（社内で唯一の共通ステージング環境兼CIサーバーとしてさくらVPS512を別途借りています。）

ミドルウェア

OS：Debian Squeeze

Webサーバー：nginx（静的ファイル配信）

Appサーバー：unicorn

DBサーバー：MySQL

Ruby：1.8.7

Rails：3.0.8

CI：Jenkins

Deploy：capistrano

Testing Framework：shoulda

Integration Test：Test::Unit + Capybara（Capybara.default_driverはWebkitとSelenium）

Fixture Replacement：なるべくfixturesをそのまま使う。

Mock：なるべくfixtures、実DBを使って時間や外部サービスの部分につかうMockは検討中。
（プログラマーが１人なのでテストの実行時間は余り気にならない。寧ろテストコード作成をどれだけ短時間でできるかを重視しています。）

（RubyとRailsはRails3.1が正式リリースしたらRuby1.9.2, Rails3.1にアップデートしようと思ってます。）

サーバー監視

pingdom

昔作ってたサービスではLivedoorデータホテルパトロールやmontasticなどを
使ってました。pingdomは無料プランの制限がキツイのでhttp://mon.itor.us/を検討しています。）

参考：ホントに小規模なサービス運営者のためのサーバ監視入門 – もぎゃろぐ

リソース監視

Librato Silverline

各ソフトウェアのCPU・メモリ使用料などを素敵っぽい見た目で見せてくれます。Githubが使ってるらしい。CPU 8 Coreまで無料なのが嬉しい。さくらVPS512は2 Coreなので。

開発フロー

デザイナー：@mahicda

プログラマー：@komagata

の二人で作っています。

1. Github IsseusにIssueを登録する。（Privateリポジトリ）
2. プログラマー・デザイナー共にローカル環境でテスト・実装し、Githubにpushする。
3. LingrのFJORD, LLCに通知が来る。
4. GithubのPost-Receive URLsで自動的にJenkinsのテスト+ステージング環境

（kowabana.fjord.jp）へのデプロイが行われる。 （コケた場合はメールで通知が来る）

5. ステージング環境でiPhone+Androidでの動作確認をし、問題無ければ@komagataがローカルからプロダクション環境にデプロイ（$ cap production deploy）する。
6. 1に戻る。

社内の情報のやり取りはIRCではなくLingrを使っています。（IRCはデザイナーにちょっと敷居が高いきがするので。SkypeはP2Pなので2人のログインタイミングによっては暫く情報共有されないことがあるので。）

感想

僕も@machidaさんも以前の会社では社内サーバーにSVN+Skype+Redmine+capistrano+cronベースのCIを行っていたので、ツールがちょっと変わったぐらいで基本的なフローは対して変わっておらず、あまり戸惑うことはありませんでした。

とはいえ、移行前につかっていたHerokuに比べれば大分面倒です。Lokkaの開発で使っていますが、オープンソースであれば、Heroku + Travie-CIの方が楽かなとは思います。

サーバーの性能に関してはHerokuに比べたら面倒な代わりに大分余裕がある感じがします。さくらインターネットは国内バックボーンへの回線が凄く太い印象があります。今までの経験からの超感覚的な数字なんですが、Railsプログラミングで特殊なキャッシングなどをしなくても50万PV/月ぐらいは全く問題無さそうなイメージです。Herokuは楽ですが、2 Dynosになった時点でさくらVPS512よりお金掛かるので・・・。

50万PV言ったら単にDBサーバー用にさくらVPS512をもう一台借りるかなあぐらいに楽観しています。

スマホならではの部分では、見た目小さいですが、画像の解像度が相当高いので写真などの画像ファイルのサイズがかなりデカイです。画像の代わりにCSS3のエフェクトを多用したり、画像ファイルの最適化がサイトの表示スピードに体感でもかなり影響する印象を持ちました。

後はiOS用にトップページのアイキャッチ的なアニメーションはHype(CSS + JS)を使っています。これについては@machidaさんが後で詳しく書いてくれるハズ！

スマホWebで楽なのはJS+CSS3が思い切り使えることです。一応PCからも見れますが、前述の利点を活かすためにIEを捨てました。（Chrome, Safari, Firefoxを使うように警告が出来ます。）

問題点

• Androidエミュレーターが遅すぎる。ステージング環境にアップされてからか、ちょっと思いProxyLocalを使って実機（僕が持ってるので）で確認する必要があるのでもどかしい。
• システムとデザインなど、手分けする必要があるタスクはそのままではアップできない状態でコミットされる。（システム面は実装したけどデザインが入ってないからproductionにはアップできない状態になり、リリースのタイミングを調整する必要がある）

  これは@machidaさんがGithub.appでのリモートブランチの使い方を習得しつつあるのでリリースブランチを作れば解決しそう。（デザイナーには酷な気がするが・・・）

View Comments

blog comments powered by Disqus