サブスクリーンについて、または高専カンファレンス100 について。
Kosen Advent Calendar 2015です。 最初の高専アドベントカレンダーは2010年ごろから始まっていたようですね。最初のほうは june29 さんがGoogleGroupなどで呼びかけていたのを覚えています。それが今は ADVENTAR というWebサービスによって*1、誰でも高専のアドベントカレンダーを開催することができました。
さて今回はサブスクリーンについてと、先週行われた高専カンファレンス100について書こうと思います。
サブスクリーンについて
サブスクリーンというのはカンファレンスなどのセッションでメインのスクリーン、つまり登壇者が自分のスライドを表示するスクリーン、とは別のスクリーンのことを指します
このようなサブスクリーンの初出は RubyKaigi っぽくて、僕が調べる限りでは2008年の RubyKaigi にはすでに存在しているようでした。*2この時は今のようにTwitterのタイムラインをするのではなく(Twitterが世に出てまだ1年目ですね)IRCのクライアントを表示していたようです。
サブスクリーンが提供する機能について
サブスクリーンが提供する機能は基本的には何でもよくて、例えば、RubyKaigi 2008 で行われたIRCのクライアントを表示するものいいでしょうし、今だったら、UserStreamに対応したTwitterクライアントでハッシュタグで検索した画面を表示するのもいいでしょう。これはとてもミニマムな構成なので、プロジェクタとスクリーンと専用の端末があればサブスクリーンは運用可能です。
またリッチな機能としてはサブスクリーンに画像を表示させたり、LTのタイマーを表示させたりすることもできますし、サブスクリーンとしての用途は様々です。
サブスクリーンにはTwitterやIRCのクライアントアプリを表示するのとは別に、開催の用途に合わせた専用のWebアプリケーションを実装することもあります。この実装に関しては後ほど解説を交えつつ紹介したいと思います。
僕が今までにやったサブスクリーンの運用
あまりしっかりとは覚えていないですが、5周年記念パーティの時が初回で、その後高専カンファレンス in 北海道3でもやりました。地元のイベントでお願いされてTwitterのタイムラインではなく内輪向けのチャットツールのメッセージをサブスクリーンに表示するアプリの運用、RubyKaigi2014にて設営のお手伝いなどで経験しています。
こうしてみると運用回数は少ないように見えるけど、実際に運用すると本番一発勝負なので、当日に問題が発生してそれを回避するワークアラウンドな対応をしまくって、勢いよく知見が溜まってきます。自分でコントロール可能な状態にしておいても何かしらの問題は発生するので、一度でも運用を経験するとサブスクリーン結構たいへん、というのがわかると思います。
高専カンファレンス 100 のサブスクリーン
さてここからそのサブスクリーンを高専カンファレンスで運用した話。
12月19日と20日に高専カンファレンス 100 というイベントをやりました。僕は基本的には会場設営(特に借りる備品類の管理)をやる傍らでサブスクリーン芸人としてサブスクリーンの設営と運用をしていました。
サブスクリーンのプロじゃないんだ… #kosenconf
— そらは (@sora_h) 2015, 12月 19
@sora_h 金で解決してこそプロ。
— あそなす (@asonas) 2015, 12月 20
当日は、4トラック同時で走るセッションがあったので、最低でも4枚のサブスクリーンを用意する必要があったり、サブスクリーンの設営や運用には僕1人だけだったのでなるべく手放しで運用できるような設計をするのが一つの課題でした。
会期中の機材については、電通大の先生やスタッフでプロジェクタやスクリーンを持ち寄ることで最低稼働数を確保できました。電通大の水戸先生、@denari01くん @crimsonwoodsさん、ありがとうございました。
サブスクリーンの実装
ここでサブスクリーンの各種実装について説明していきます。もし、自分がカンファレンスを開催することになり、サブスクリーンを運用してみたいというときには、この章を参照してみてください。*3
各種、というだけ実は様々な実装がこの世には存在します。といっても実装している人たちはほとんど同じなので中身のコードなどは似通っていることもあります。
ruby-no-kai/kaigi_subscreen
これがWebに公開されている一番最初のサブスクリーンの実装ではないでしょうか。
僕はこの実装を使って 2013年に開催された高専カンファレンス5周年記念パーティで運用をしました。その際にぶち当たったことなどは当時ブログにしていました。
一番ベーシックな実装ですが、TwitterとのAPIの互換が壊れている部分があるので、今から運用に持っていくのはあまり得策ではないと思います。
aun-signage/aun-subscreen
最も安定したサブスクリーンの実装で、高専カンファレンス100でも当初はこの実装を使って運用を考えていました。
運用に乗せるための手順はREADMEにかかれている通りに設定すれば動作可能です。
aun-signage/aun-reciever と aun-signage/aun-subscreen:ng
こちらは上記の aun-subscreen のGo実装になります。GitHubで ng というブランチに切り替えるとわかりやすいと思います。ちなみに aun-subscreen はmasterはNodeで実装されています。
同様にREADMEに書かれている内容を実行することでそのまま運用にのせることができます。こうしてみると、READMEに書かれていることをそのまま実行することで運用に載せられるのは素晴らしいですね。
この実装の特徴は IRC やタイムラインのメッセージを取得するアプリケーションと、それを表示するためのアプリケーションを分離したことです。
1つのアプリケーションでメッセージの収集と表示をするとスケールさせたいときに困るので、こういう形で機能単位で分離してるととても便利になったと思います。後述しますが、高専カンファレンス100ではこの aun-receiver を利用することになります。
元祖 aun
こちらはインターネットには公開されていないのですが、aun-subscreenに管理画面機能やアナウンスメント機能、画像を表示する機能などの機能を実装した特盛サブスクリーンが RubyKaigi 2013 で使用されていました。
また今回の最終的な要件として、aun-subscreenだけでは開催中の運用に耐えられないということがわかったので、この元祖 aun の一部機能を真似たアプリケーションを再実装することにしました。
asonas/aun-noko9
aun-noko9、、、あうんのこないん、、、あうんのこkyu
はい!というわけで Yet Another Aun Subscreen(YAAS)です。このサブスクリーンは、先ほど紹介した aun-receiverと一緒に運用します。使い方はREADMEに書かれている通りで、heroku create
をしてherokuにデプロイをして、いくつかの環境変数を設定することで運用を始めることができます。aun-scscreen が Node での実装に対してこちらは Rails での実装になります。ただし、ほとんどがJavaScriptでコアの機能を実装をしているので、管理画面以外で両者には差異はあまりないです。
細かい話でいうと、特定のアカウントのつぶやきを表示させない機能*4や、正規表現で特定のつぶやきを表示しない機能などがあります。たとえば ^RT
と設定することで、RTされたつぶやきを表示しないなどできます。スパムアカウント対策と同様NGワードを設定することも可能です。*5
このアプリでは、Twitterのタイムラインメッセージの表示機能と管理画面から運営からのお知らせを表示する機能を提供しています。
タイムラインではTwitterで受け取ったメッセージを表示して、
管理画面では運営からのお知らせを表示させています。このお知らせを投稿したらすべてのクライアントに対して配信をしています。お知らせの配信に関しては自動でやっているので、クライアントの再起動などは必要がありません。
管理画面について
管理画面を用意してあり、運営からのアナウンスなどを表示することができます。また、何かトラブルがあったときのためにデバイスすべてに対する再起動するためのボタンが設置されています。
運用上必要になったので各クライアントがちゃんとネットに繋がって動いていることを保証するハートビート機能(通称Watchmen)を実装したのですが、見られてはダメなものがハードコードされているところがあるのでまだmasterにはコミットされていませんが、気合をいれて修正をしたいと思います。
www.instagram.com (慌てて便利機能を実装していた様子)
サブスクリーンの運用
基本的には手放しで運用が可能でした。特に1日目は新しいコードのデプロイ以外ではクライアントを再起動することはありませんでした。
二日目にはMQTTとのコネクションが切れることが頻発していましたが、複数トラックの発表も終盤だったのでなんとかなりました。
原因はよくわかっていないのですが、今回は CloudMQTT の無料のプランを使っていたからか、最後のLTのセッション中にも MQTT が応答しなくなり、CloudMQTTの管理画面から再起動を繰り返した挙句、最終的にはプランをひとつあげることで回避しました。
おまえらの皆様のツイートの流量に耐え切れなくてインスタンスが落ちたので強くして帰ってきたサブスクリーンです #kosenconf
— あそなす (@asonas) 2015, 12月 20
課金の様子です。 #kosenconf pic.twitter.com/fZB3ECpPZJ
— あそなす (@asonas) 2015, 12月 20
aun-noko9の今後
カンファの最後にWebサービス化すると言いましたが、最終的にはWebアプリケーションに詳しくない人でも使えるようにしたいので、なんらかの形でWebサービスにしたいと考えています。一番最初にできることは app.json を配置してHeroku Buttonで一発起動とかでしょうか。*6
Webサービスにした時のWebSocket周りの通信で悩んでいるところにRails5が出てきてActionCableとか謳っているのでもしかしたらそちらに乗り換えるチャンスかも。
あと、名前は変えると思います。
増えるサブスクリーンの実装
さて、サブスクリーンの実装についてですが、再実装や公開されないコードなどが出てきていますが、これはなんというか仕方ないことだと思っていて、サブスクリーンがそのカンファレンスの実装に強く依存していて汎用性が高くないことがあると思います。(オープンソースにしてもオーバースペック感とかある)
なので、各々カンファレンスの実装に合わせてサブスクリーンをやりたい人が他の実装を真似ていくのは別によいかなと最近は思うようになりました。もちろんミニマムな構成を採用したければ aun-signage/aun-subscreen の master ブランチを使うか適当なTwitterクライアントを使うのが一番手っ取り早いでしょう。
また自分のカンファレンスに合わせた機能が欲しければ aun-subscreen や aun-noko9 をforkするのもいいですし、それらを参考に自分の好きな言語やフレームワークで1から実装するのもいいと思います。
より高機能なサブスクリーン
今回サブスクリーンを運用する上で制約上できなかったことを挙げてみます。
より楽な運用ができて、見た目が華やかなサブスクリーンを目指したい。という個人的な展望です。
専用デバイスを用意できなかった
当初サブスクリーンを表示するデバイスはiPhoneにしようと考えていました。理由としては軽くて持ち運びや設定が楽、Lightning対応であればHDMI出力がすぐできる。といったメリットがありましたが、今回借りるプロジェクタがVGAしか入力できなかったので、僕の部屋にある4本のLightning2HDMIケーブルは使われずにお蔵入りとなりました。
そのため僕はMacBook{Air,Pro,ProRetina}の3台と開発マシンのProRetinaの合計4台を持ち運ぶことになりかなりしんどかったです。
また、VGA対応のプロジェクタしかなくとも、対応するコネクタを買えばよいので、開催費に余裕があれば機材購入をしてサブスクリーンの設営がより楽になることでしょう。
この辺りの改善策としては hmsk さんが書いている記事にあるように、スティックタイプのデバイスとHDMIに対応したプロジェクタを揃えることがハードウェア的な面で取り扱いが楽にりますね。予算とのトレードオフですが、個人でHDMIのプロジェクタとデバイスを揃えておきたい気持ちが出てきました。
縦置き表示をしなかった
こちらはスクリーンの都合で出来なかったのですが、基本的にタイムラインというのは縦に長いものなので、プロジェクタを縦置きにして置くと見た目かなりインパクトが大きいですね。縦置き表示はRubyKaigi2011で実装されていた記憶があります。
複数セッション時にタイムラインを分割しなかった
複数セッションがあり、それぞれの部屋ごとにハッシュタグが割り当てられていたのですが、そのハッシュタグごとにサブスクリーンに表示するタイムラインを分けようとおもったのですが、実装時間がなかったのでやりませんでした。
後述しますが、あまりサブスクリーンがメインになるような機能の実装も考えものだなぁと思うのでした。
今後のサブスクリーン
サブスクリーン歴3年目ぐらいですが、昨今思うこととしてはサブスクリーンはもう少しサブに徹したほうがいいのかなと思うようになってて、サブスクリーンを運用する身としてはサブスクリーンに流れてくるツイートとともにセッションを進めてくれるのもうれしいのですが、サブスクリーンがメインコンテンツになってしまっては本末転倒だな、と思うので、サブスクリーンの演出は今後の課題だと思います。
例えば、セッション中に表示する情報を登壇者のプロフィール情報にしたり、運営からのお知らせを流すなど、流れ行くメッセージだけを垂れ流さないで聴者がセッションに集中できるようにしたり、発表終了直後にTwitterのタイムラインを表示して、質疑応答時に登壇者の方にサブスクリーンを見せつつ質疑応答の一助をしたりなどなど、タイムラインを表示するにしても演出の仕方を少し変えてみると面白いかもな、と。
また、今回はじめて大規模な開催でのサブスクリーンを運用(しかも最大4セッション!)して初めて思ったのはサブスクリーンの実装はそのイベントに強く依存するのだと思いました。今回は開催するにあたって足りない機能をもりもりつくっていたらこうなった。みたいな感じで、多分普通の1トラックの開催では管理画面は不要だと思いますし、アナウンス機能も実は...ということもあります。なので
なぜサブスクリーンをやるのか?
サブスクリーンは僕の趣味であるとは言ったものの、趣味以上にカンファレンスのひとつの常設コンテンツとしてサブスクリーンを活用するには?みたいなことを考えているところがあるのかもしれません。あとは単純に僕がWebアプリケーション開発者でプログラミングが趣味、ということもある。
カンファレンスの常設コンテンツの考察をしていたいというのと、プログラミングをすることが趣味なのでいくつも再実装をしても苦ではないという感じでしょうか。モチベーションの維持についてはカンファレンスが開催されることになってからがつくることでそれなりに「サブスクリーンやるぞ!」という気持ちも大事だと思います。開催三日前に「やるぞ!」って気持ちになっても遅いのでなるべく早めの段階でサブスクリーンに対するスタッフ内の温度感を高めて置くこともまた大事でしょう。
また、サブスクリーンはカンファレンスにとって必要なものではないということも添えておきます。なければ困る、ということは無いと思いますし、サブスクリーンを運用するコストがスタッフ内でカバーできるのかも割りと重要な感じがします。無理してサブスクリーンを運用するよりはカンファレンスの身の丈に合わせて要件などを調整できる力も求められると思います。
まとめ
僕が陰ながらやっているサブスクリーン業についてお話しました。
世にたくさんあるサブスクリーンの実装について僕が知るかぎりの説明をしました。aun-signage/aun-subscreen の master が一番設定が平易で安定して使えます。おすすめです。単純にサイネージとしても映えると思うので、適当にherokuにデプロイして空いているディスプレイに表示しておくだけでも楽しめると思います。
サブスクリーンの今後について話してみました。サブスクリーンの実装はカンファレンスの実装に依存します。僕が書いた aun-noko9 や、aun-signage のサブスクリーンが他のカンファレンスでもマッチするかどうかはわかりません。高機能なサブスクリーンを目指すよりも、まずはサブスクリーンでなにをしたいのかを考えるところからスタートしたり、僕みたいに何度も再実装をせず、Twitterのタイムラインを表示するだけでもやってみるとよいと思います。
サブスクリーンを運用する人として、サブスクリーンの演出の仕方を考えていきたいと思うようになりました。タイミングがよければどこかのカンファレンスでまたサブスクリーンを再実装することになるかも。これは僕が考える宿題ですね。
またサブスクリーンを運用したいなどの相談があれば気軽にTwitterとかで話かけてください。お手伝いできることあるかも。