オンラインカンファレンス向け事前収録システムを作った #iosdc

9/19〜9/21にiOSDC Japan 2020を主催しました。今年の開催は初のオンライン開催で、レギュラートーク(20分・40分)はすべて事前収録とし、当日は編集済の動画を配信する方法を採りました。

このエントリではiOSDC Japan 2020のために構築した事前収録システムについてその構成やハマりどころを解説します。

TL;DR

2017年から開発・メンテナンスしているカンファレンス運営支援システムの fortee に収録 & 編集機能を実装しました。1

いくつかのサービスのAPIやWebhookを使って以下の様なことをしています。

続きを読む オンラインカンファレンス向け事前収録システムを作った #iosdc

iOSDC Japan 2020 を主催した #iosdc

9月19日(土)〜9月21日(月・祝)の期間でiOSDC Japan 2020を主催しました。

初のオンライン開催

5回目・5年目の開催となる今年でしたが初のオンライン開催でした。

年が明けてさて準備を本格的に始めるぞ、と思ったらあれよあれよという間に状況が変わり、オフライン開催なんてとても考えられない状況になってしまいました。

それでもワンチャン🐶9月に収束して…なんて考えていたのですが5月下旬にはさすがに諦めてオンライン化を決めました。

ここ数年は “Please stay connected with us” と言っているので「開催しない」という選択肢はとりたくなく、オンラインでの開催としました。

その時点で数社のスポンサーさまにお申込頂いていたのですが、引き続きご支援頂きました。本当にありがとうございました…!

今開催の”ミッション”

今回の開催では「ちゃんと開催する」をミッションとして準備を進めました。

iOSDC Japanは過去4年の開催では比較的リスクを取って新しいことをしてきたのですが、今回はほぼ全てが初の経験になるのでリスクは最小限にして「ちゃんと開催する」をミッションにしました。

そのため、トークは「基本は全て事前収録、事前収録がうまくいかなかった場合は一部 or 全てライブ」としました。

LTについては悩んだのですがiOSDCのLTは5分で強制終了するタイプなので事前収録と相性が悪いよな…ということでZoomによるライブの形をとりました。

事前収録については自作のカンファレンス運営支援ツール fortee に機能実装してこんな風にやっていました。

  • Zoomアカウントを複数用意する
  • fortee: Zoomアカウント分レコーディングトラックを作成
  • fortee: レコーディングトラックの中にレコーディングスロットを作成
  • スピーカー: レコーディングスロットを予約
  • fortee: レコーディングスロットの開始時刻になったらZoomにミーティングを作成
  • fortee: スピーカーがZoomミーティングに参加したら:
    • Zoomクラウド録画を開始
    • YouTube Liveを作成してZoomミーティングからストリーミング開始(スピーカーの確認用 & バックアップ録画)
  • スピーカー: 画面共有し、収録する
レコーディングスロット

その後の編集についても「fortee 経由でZoomから(画面共有とスピーカーの顔カメラの)クラウド録画をダウンロードして、ローカルで再生してIN/OUT点を確認、fortee にIN/OUT点が入力されるとスポンサーロゴなどが乗ったフレームに合成 & 入力されたIN/OUT点で切り出して10秒間のカバー動画を先頭に付けてDropboxにアップロード。アップロードされた動画をスタッフが最終チェックして完了」的な自作システムでしました。

一連のもろもろについては別記事を書こうと思っています。(仕組み的には大したことないのですが、いろいろハマりポイントがあるのでメモっておこうかと…)

ノベルティボックス

iOSDC Japanはオフライン前提の設計になっているので、スポンサーさまにお返しする価値にはスポンサーさまのノベルティやフライヤーを参加者のみなさまに直接お渡しすることも含まれていました。オンライン化してもそこは守りたく、ノベルティボックスの配送というチャレンジをしてみました。

ノベルティボックス

とは言っても、実は毎年エコバッグへのノベルティ封入をお願いしている業者さまが配送サービスも持っており、そこにそのまま乗らせて頂いたので大きなリスクとはならない想定でした。

バリデーションが無い住所フォームであるがための誤入力が一定数発生し、確認のやりとりをする必要があるのが運営負荷としてはキツかったですが、これは仕方ないかな、と思っています。

配信プラットフォーム

オンラインでのカンファレンス開催の経験はなく、配信サービス選定からする必要がありました。

iOSDC Japanは初回から「お金を払ってでも参加したい方のためのカンファレンス」にしたいと思っていて、それを前提とするとYouTube Liveは使えませんでした。Vimeoはじめいくつかの配信プラットフォームを検討する中でひょんなことからドワンゴさま & KADOKAWA Connectedさまのサポートを頂けることになり、ニコ生での開催が決定しました。

配信そのものはRTMPで送信すれば良いので特に不安はありませんでした。

iOSDC Japanでは2019年にPAシステムを構築しました。このシステムの映像系最終段階がOBS Studioなので、そこからRTMP送出をすればOKで、実際にリハーサルや当日にも特にトラブル無く配信することができました。

個人的にグリーンバックでの撮影をやってみたかったのでPAシステム構築の発起人であるスタッフのrela1470さんに相談したらOBS Studioに機能があるとのことでトライしてみました。

クロージング

いやー面白かった。大満足でした。

バタバタしてはがれるグリーンバック

ニコ生おもしろいですね!オンラインカンファレンスはニコ生が鉄板なのでは?と思うぐらいに良い体験でした。

おそらく現在は一般向けに公開された機能だけではiOSDC Japan 2020の様に「1シリアル・複数トラック・複数日開催」のスタイルでの開催はできないと思いますが、今後に期待したいですね!

The iOSDC Anthem

ニコ生コメントで幕間に「この音楽何?」というコメントを見かけた気がしますのでご紹介です。

オープニングや幕間で流している曲は、 The iOSDC Anthem です。これは作曲家の古代祐三さんにiOSDC Japanのために作曲して頂きました。

古代さんは長谷川の年代の方でゲームがお好きな方には”神”の様な存在ですよね!「イース」「イースII」「ソーサリアン」「アクトレイザー」ですよ!最近だと「世界樹の迷宮」シリーズでしょうか。

この曲は尺違いの3パターンがあって、オープニングで使っているのはショートバージョンでした。今年は幕間でフルバージョンをたっぷり流せて幸せでした。

と言う訳で…

ご参加頂いたみなさま、ありがとうございました!

そして、ブログやトークへのフィードバック、ありがとうございます。例年より数がとても多く、すごく嬉しく思っています。

どんな形態になるかはわかりませんが、来年以降の開催では今年のオンライン開催の経験も生かしてより良い iOSDC Japan にできるだろうな、という気がしています。

来年もiOSDC Japan でお会いしましょう!

HTTPの下の方

先日こんなツイートをしました。

思ったより多くの反響をいただいて、その内容を見て「これはあまり良くない質問だったかもな」と思ったので今後封印すると共に「自分だったらこう答える」というのを書いておこうと思いました。

元が面接の話なので、調べないで時間をかけないように書いてるので間違ってたら教えてください!!

POSTとGETの違い

  • どちらもHTTPメソッドでプロトコル的に本質的な違いは無い。
  • リクエストが「GET URL HTTPバージョン」になるか「POST URL HTTPバージョン」になるかの違い。
  • 世の中の実装ではパラメタの受け渡しがGETではURL、POSTではHTTPボディがメイン。
  • ブラウザ実装面ではリロードする時にGETは確認なし、POSTは確認を伴う実装が多い。
  • 検索エンジンbotなどはGETを辿ることがあり、GETで取得できる画面には副作用が無いものを置くのが望ましい。
  • そういえばちゃんとRFC読んだことないのでちゃんと答えるには読んだ方がいいな…。(URLの「?」の後ろがどういう扱いになるべきかを理解していない。POSTで「?」を使うことも実装上は可能。)

Cookieの仕組み

  • ステートレスなHTTPでステートを実装するための仕組み。
  • サーバはHTTPレスポンスヘッダの Set-Cookie でキーと値、送信して欲しいドメイン、有効期限を送信する。
  • ブラウザは Set-Cookie ヘッダを見たらその内容をローカルファイルなどに保存する。
  • ブラウザはHTTPリクエスト時に保存したローカルファイルを検索してドメインで検索して以前に受信したCookieがあればHTTPリクエストヘッダ Cookie として送信する。
  • ローカルに情報が保存され、改竄される可能性があるため秘匿情報を保存する用途では使用しない。

PHPのセッション

  • Cookie同様にステートレスなHTTPでステートを実装するための仕組み。
  • Cookieと違い情報をサーバ側に保存する。
  • サーバは情報を保存したいタイミングでファイルなどに値を保存しそれにキーを割り当て、Cookieでそのキーを送信する。
  • ブラウザ側から見ると通常のCookieと同じ。
  • サーバに情報が保存されるので、データの改竄の心配はしなくて良い。
  • Cookieの盗難や、キーの生成規則の脆弱性、不適切なキーの受け渡しによる経路での盗難によってセッションをハイジャックされる可能性がある。
  • 情報がいつまで使えるかはCookieの期限に依存するが、サーバ側に情報を保存するため無限にそれを保存することは難しく、言語やミドルウェアによってセッションの有効期限を決めてそれを過ぎた情報は削除される実装になっていることが多く、2つの期限を意識する必要がある。PHPもそう。
  • PHPの場合、セッションキーのやり取りはPHPに隠蔽され、スーパーグローバル $_SESSION経由でアクセスできる。Cookieのキーを振り直す関数など、セッションの運用をサポートする関数が実装されている。

そんな感じですかね!皆さんの想定とあってます?「そんなので良いの??」という方!いいですね!ぜひ一緒に働きましょう!!!

デジタルサーカス株式会社 採用情報

こういうのを見て「なるほど〜!」「そうだったのか〜」「もっと知りたい!」という方もぜひ!

キミは世界を変えるチカラを持っている

転職面接のFAQで「何で前職を辞めたんですか」というのがありますが、それに対して一般的には「ネガティブな答えはNG」ってされてると思います。

その理由は、面接官から「その状況を変えようとしましたか?」みたいな質問になり、その質問に対する「良い答え」の難易度がとても高いから、というところだと思います。(ちゃんと答えられれば評価爆上げですが、そもそも博打ですよね!)

で、ですね。「変えようとしたか」というのが今日のテーマです。

言いたいことファーストで言うと「不満点は表明すれば自動で解消される可能性がある」「辞めるならあなたが積み立てた信頼貯金(クレジット)を使ってからの方が良い」ということです。

会社で仕事をしていれば仕事内容、自身への評価、給与などに対する不満は出てくると思います。そしてその不満が溜まると人は転職すると思います。今日オススメしたいのは転職の前に「不満は表明しよう」「信用貯金は使おう」ということです。

世の中では「不満を言うなら解決策も示せ」とか「その解決策に向けて邁進せよ」みたいな話になりがちなのですが、それって極論で、その手前に「不満を言ってもらったことで進んで会社がその不満を解消する方向に動く」ということもあるんです。つまり「解決策など無くても不満は表明した方が良い」ということ。(そもそも解決策は本人が考える義務が無いものが多いですよね!)

みなさん、会社や職場で嫌なことがあったらまずはフィードバックしてみてください。「◯◯が××なのが気になっています。解消されないのであれば退職したいと思っています」とか「◯◯がすごく気に入っています。これが無くなったら退職すると思います」とか。

これを聞いた人は「ごもっとも」と思えば問題を解消するでしょうし、そうでなかったとしても「それを解決するコスト」と「その人が退職してしまうダメージ」を比べます。

あなたが評価されている(=信頼貯金が貯まっている)のであれば「退職してしまうダメージ」が大きく、「それを解決するコスト」が高くても釣り合いが取れるでしょう。

あなたの第三者からの評価はあなたからは見えないですが、自己評価はあると思います。

不満を表明した結果、自己評価ベースで納得いかない返答ならスッキリですね!次の職場を探しましょう!否定的な回答でもその返答に「仕方ないな」と思ったらその場にとどまっても良いですね。

会社は意外とみなさんのことを考えています。異動やプロジェクトアサインは多かれ少なかれみなさんのキャリアのために、という考えが含まれています。つまり「良かれと思って」やっています12

そして、前にも「転職とサッカーとコミュニティ」というエントリで書きましたが、プレイヤーはその場その時で活躍できなくても別のチームに行けば即活躍できることもあると思います。

自分の思いをアウトプットし、それが今のチーム(会社)と合わなければ、今自分を求めてくれるチームを探して移籍するのも良いですね。

ただ、今そういうチームがあるということは、未来に再度移籍する先が今のチームの可能性もあります。そのためにも、納得し、納得してもらい、惜しまれて移籍しましょう。これは本当に大事なことです。

どこに落とすと良いのかを見失ってきましたが、今日言いたいことはそのぐらいです!

Happy Hacking!!!

PHPerKaigi 2020 を主催した #phperkaigi

去る2020年2月9日(日)〜2月11日(火)に、PHPerKaigi 2020 を主催しました。

PHPerKaigi は第1回が2018年なので3回目の開催になります1

長谷川は PHPerKaigi に加えて iOSDC Japan の主宰もしており、今回で7回目の草の根技術カンファレンス主催でした。今回はその中でも一番、「今回はやり切ったな」「もうこれ以上やることは無いかもしれない」と思う開催でした。(まあ毎回そんな風に思っているのですが)

今回はPHPer茶会2、PHPerチャレンジ3といった2019年導入の企画はそのまま据え置き、会場の新スペース開拓、トレーディングカード、コードゴルフといった新企画を追加しての開催でした。

トレーディングカード

今年の当たり企画はこれですね!

参加者の名前とTwitterアカウント & アイコンが印刷されたカードを作って、チケット早期購入特典として4みなさんに100枚ずつご自身のカードをお渡ししました。

自己紹介の名刺として使って頂ければ、と思っての企画だったのですが、会場ではその思惑以上に良く機能していて、企画者として高揚感がありました。

PHPerトレーディングカード

長谷川は大学生時代に Magic: the Gathering (M:tG)というTCGをたいへん熱心にプレイしていて、今回のTCGはその影響を強く受けています5

今回配布したカードは、49種類のカードテキストの「クリーチャー」に参加者の一部220名を一定のルールでランダム割付したものでした。

内部的にはこれに加えて20種類の「呪文」と20種類の「装備品」を加え、79種類のカードセットを使ったゲームを想定していました。ルールも考えていたのですが、テストプレイをして調整をしたり呪文と装備品のイラストを作ったりする時間が取れずこの形でタイムアップとなりました6

はじめてのテストプレイ

欲を言うと市販のトレーディングカードゲーム(TCG)の様に10枚なり15枚でランダム包装したかったところですが、こちらは印刷のお願い先との調整の時間が足りなく断念しました。

PHPerトレカのつくりかた

基本的には、ADPRINTさまのトレーディングカード スタンダードサイズ(大)という商品です7

入稿は Illustrator ファイル1ファイルにつき30種類を割付したファイルなので参加者 & カードのデータCSVと事前取得した参加者のTwitterアイコンファイルを Illustrator JavaScript で割付しました8

絵柄面の枠外にチケット番号を印刷しておき、受付時にチケット番号から探してのお渡しでした。モノが場所を取るのでなかなか難易度の高い受付でしたがそこは印刷された名札を探すのに熟練したPHPerKaigiスタッフたちの力でなんとか回すことが出来ました。感謝!!

大分満足だったトレカですが、これからどうしようかね〜と思っています。今のルールだとゲームに10分〜20分ぐらいはかかってしまいそうです。実際にカンファレンス会場でテストプレイしてみるとちょっと厳しい気もしています。

これからじんわりと考えていこうと思います。

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

という訳で、PHPerKaigi 2020 にご参加くださったみなさま、ありがとうございました!

現時点では2021年開催は予定していませんが、今年もみなさまにとてもお楽しみ頂けたと思うので来年も開催したいと思っています。引き続きご支援お願いいたします!!

そう言えば、第1回の「金曜日 + 土曜日」、第2回の「金曜日 + 土曜日 + 日曜日」に対して、今回は「日曜日 + 月曜日 + 火曜日(祝日)」という変則的な日程での開催でしたが「平日は休めない」というお声や「火曜日は定例リリース日なので休めない!」というお声を頂き、なるほどなーと思っています。ごめんなさい!次回から最大限土日を含んだ日程にします!!