ストーリーボードのバックエンド等々のお話

プログラム ストーリーボード

ストーリーボードをSqale(http://sqale.jp )へ運用を移管したのは以前簡単にここにも書きましたが、一度どういった技術を使っているのかまとめがてら整理してみます。

実装

現在、実装周りでは、

などを利用しています。

Youtubeの動画を連続して再生することができるYoutubeプレイヤー REMP(http://remp.rockf.es/ )のころからのスタイルでサーバ再度側は基本的にAPIが主体となる様な設計になっており、WebUI上からの操作をJSが吸収して、サーバサイドのAPIを叩き、その応答をJSが再びUIへ反映させるといった構成になっています。
私が担当したサーバサイド側の実装では、大きく分けて、

  • 最低限必要なページの生成
  • 編集されたプレゼンテーションドキュメントの保管
  • プレゼンテーションに利用する画像の保管
  • プレゼンテーション操作（ページめくり等）が行われた際のページめくり情報のWebsocket配信

等を行なっています。

プレゼンテーション自体のデータ(=Markdown記述)は現在Sqaleでは共用MySQLサーバは提供されていますが、今回はMongoDBを利用しているため、ここのみ外出ししたMongoDBに接続し保管しています。
また、プレゼンテーション用にアップロードされた画像はヘテムル(http://heteml.jp )へAmazonS3互換の動きをするfS3を導入してアップロードされた画像をストーリーボードのサーバーサイドプログラム側からS3プロトコルで画像をストアしています。

更にストーリーボードの一つの特徴であるページめくり等を同じ時間にプレゼンテーションページを閲覧しているユーザにページめくり操作をマルチキャストしたり、閲覧中のプレゼンテーションに対してリアルタイムで"いいね!"をすることができる機能を実現するためにWebsocketを導入していますが、ここは現在Websocket ASPサービスであるPUSHERを使っています*1


監視サービス

監視サービスですが、Pingdomを使っています。
基本有償サービスですが、1サイトのみであれば無償で利用できます。

HTTP疎通の死活監視を行なってくれるので、最低限の状況は把握できるので役になっています。


利用状況解析

お約束感がありますが、mixpanelとgoogle analyticsを使っています。
RubygemsにmixpanelというGemがあるので、これを利用してストーリーボード上のAPIが呼び出される度にログを記録する様にしています。
基本、ストーリーボード上で何らかの操作が行われるとストーリボードのサーバサイドAPIが叩かれるので、ページめくりAPIが多いとどこかのプレゼンテーションの発表に利用されたかな。とか利用状況がわかったりします。


こんなかんじです

以上大雑把ではありますが、ストーリーボードの実装概要をまとめてみました。
今後も機能をどんどん足していくし(と思うし)、新しい技術も今後積極的に入れていきたいのでまたある程度溜まったら記事を書こうかと思います。

*1:いつか自前で実装するといつつ、すごく気楽に利用できるので使い続けてます…