今年からの試みで、ICPC 横浜大会でスクリーンキャストを提供しました。 当日の中継動画を PC から見ると、カメラ切り替えで選手のマシンの様子が見られるようになっています。 YouTubeへのリンク 経緯 実は 2016 年くらいからこれを計画していて、今年ようやく適当なものができました。まずスペックが右往左往しました。 選手の画面を外部に提供できると、観戦の際に楽しそう スクリーンショットを外部ページにアップロードすれば良さそう 60台の1080pのスクリーンショットを定期的に外に保存すると帯域を食い過ぎる。 ユーザに提供する UI が大変なことになりそう。 実は動画で提供したほうが帯域は少なくて済む。 とは言え 60台分送るのはやはり大変だし UI も大変。 動画を中継に差し込みたいが、選択 UI とか大変そう。 裏方でも見られるようにしたい。 外野にも見られるようにしたいが、60チャンネル YouTube Live するのは正気ではない。 上を経て、世界大会のビデオ を真似ることにしました。画面を4分割して、4チームのスクリーンが流れます。5秒ごとに1チームが切り替わるので、各チームは一度に20秒だけ放送されます。 どうなるか謎な UI は無視し、とりあえずチームを全自動ランダムに選んで動画を提供します。動画提供方法を確立することを目指し、それの活用は後回しにしました。 仕様を確立した後も、やることはうまく見通せず大変でした。 ストリーミングどころか動画データすらちゃんと扱った経験がないので、何をどう構成していいか全くわからず、調べるのにも苦労しました。 やることは以下のとおりです。 60台の選手マシンから動画を受け取る。 ランダムに 4チーム選んで順次合成。 合成した動画を生放送サイトに送る。 つまり、動画ストリーミングを切り替えつつ一本にまとめる事になります。自動でできるソフトを探すかプログラムを書くかになります。何もわからず、ffmpeg streaming とか ffmpeg switch between streams とか ffmeg zmq crossfade とかで何度も検索しました。 すごく初期の実験の様子: ffmpeg x11grab しているだけ ffmpegごっこ (ライブスクリーンキャストを表示するライブスクリーンキャストをしている) pic.twitter.com/lNs1pbP3ej — Yu SUGAWARA (@gusmachine) June 21, 2016 最近の、 動画切り替えができるようになった頃の様子。 本番構成 本番では以下のシステムを使いました。結局、ストリーミングを切り替えるのを、単純に ストリーミングを送るマシンを動的にザクザク切り替える方法で対応しました。 「動画リレーサーバ」マシンを用意してコンテストネットワークとインターネットにつなぐ 動画リレーサーバは選手マシンに接続して、選手マシンで ffmpeg を起動して20秒だけ動画を動画リレーサーバに p2p で送る。 動画リレーサーバ上で OBS Studio を起動して動画を合成して Youtube Live に送る。 動画リレーサーバがいつどの選手マシンに接続するかはプログラムで指定。 動画の切り替えは前の動画の終了及び次の動画のスタートで行われる。OBSが勝手に合成してくれている。 ここがうまく行くことを知るのがほとんど全てでした。zmq は使っていません。 これを作るために、 ssh 経由で ffmpeg を起動する Go のコードを 500 行くらい書き、 VirtualBox VM を録画用と選手2台の合計3台立てて実験を繰り返していました。正直結構面倒でした。いまはテスト手法が確立したので、はるかに楽に実験が出来ます。 改善アイデア やることはいろいろあります。まずは実況システムとの連携です。上で捨てた「UIが怪しい」部分をなんとかしないといけません。 それから、当然順位や解答状況を載せるべきです。 あと、切り替えはおそらくもっとマシな方法があるのではないかと思っています。視覚効果も入れたいですが、 ffmpeg filters を見たところ外部から指定する任意のタイミングにfade in/out を入れるのは出来なそうです。

ICPC アジア予選 横浜大会で裏方をやっていました。参加者の皆様、コンテストは楽しんでいただけたでしょうか。コンテストシステム担当として、おおよそ以下の作業を行っていました。 コンテストマシンの選択 コンテストマシンイメージの作成 トライアルイメージの作成と配布 コンテストマシンへの計算機環境セットアップ コンテスト中の選手環境の監視 私は2015年からこのあたりの作業を担当していて、2016年は飛ばして今回で4回目になります。私ともう一人で担当しています。 今年は Ubuntu 18.04 へのベースシステム更新を予定していたので早いうちから作業を進めていました。 前年度大会終了直後のテンションで作業した結果、1月には主な更新が済んでいたりとか。 とは言え、ポロポロ問題が出てきたりしたため直前まで色々作業はありました。 ベースシステム更新以外にやった環境変更は以下のとおりです。 Kotlin の導入。 世界大会で導入されているエディタ (geany, kate, codeblocks) の導入。 選手画面のスクリーンキャストを導入。 上にある通り、本番前の準備が大きな仕事になるのですが、本番も会場の演題脇に座ってお仕事しています。 選手マシンにアナウンスを流したり、選手マシンを監視したり、それからマシンサポートをしたりです。印刷の仕方がわからない、に答えたり、暴走したプロセスを管理者権限で止めてコンピュータを直したりします。ケーブルが抜けたのもすぐに検知して slack に飛んでくるようにしています。 システム班の目標は自分も過去に参加した大会をサポートすること、それから、コンピュータの環境をなるべく良くすることです。特に、選手が使っていてなるべく違和感を感じないものを提供したいと思っています。近年は自前環境で参加できるオンラインコンテストが多く、それらと比較するとカスタマイズがしにくいお仕着せシステムはどうしても違和感が出てしまうとは思いますが、範囲内でできることを提供しています。

.devドメインを取り、さらに Firebase Hosting に静的サイトホスティングを移動させてしまった。 つい暇ができてやってしまった。 Hugo / Hosting on Firebase に書いてある通りにやっただけ。 すでにコンテンツがあることを前提としている。なければ適当に作って $ hugo して public/ フォルダを作ってほしい。 同時に、DNS設定の移行時間などを全然気にしていないので、前のドメインにトラフィックが多い時は困るかも知れない。 $ npm install -g firebase-tools する。 You will need to globally install firebase-tools らしい。 https://console.firebase.google.com/ へ行き プロジェクトを作成。 Hugo コンテンツレポジトリのディレクトリに移動。直下に public/ があるところ。 $ firebase login $ firebase init して質問に答える。 Which Firebase CLI features do you want to set up for this folder? Hosting. Associate this project directory with a Firebase project. 作ったやつを選ぶ。 What do you want to use as your public directory? public Configure as a single-page app? No File public/404.html already exists. Overwrite? No File public/index.html already exists. Overwrite? No $ firebase deploy で プロジェクト名.web.app や プロジェクト名.firebaseapp.com に公開されることを確認。 Hugo config の baseURL を更新しておき、 $ firebase deployする。スタイルのURLとかが変になるけどここでは気にしない。 .dev ドメインを購入。 Firebase カスタム ドメインを接続する を参考に購入したドメインを設定。 元ドメインは DNS設定でリダイレクトにする。 上記二つは設定に時間がかかるが、私の元のドメインも全然使われていないので気にしない。

ブログを再構築しました。長文を書くスペースが欲しかったので。 以前にうっかり Hugo を選んでしまったために細かいメンテナンスが積み重なっていて苦労していました。ver 1.0 以降の正式版がリリースされていないソフトなので仕方ないですが。 $ brew upgrade したらバージョンが v. 0.15 から v. 0.52 と3倍に。 テーマの書き方が変わっていて、 hugo server が動きませんでした。 使っていたテーマ はすでにメンテ終了。新しいテーマを探しました。 あるいは自前でテーマを書いてもいいですが、そんなことができるならバージョン更新で 苦労はしません。 とりあえず適当な基準でテンプレート Hermit を導入しました。 ページロードがある程度軽い。 記事てっぺんに謎の特大画像を出さない。 携帯からある程度読める。 開発が今の所継続されている。 昔はソースコードの可読性も気にしていましたが今はチェックしませんでした。長いコードは gist にでも輸出します。 あとだいたい次の作業をした記憶があります。 RSS がちゃんと出るか確認。結局全ての記事に more タグを仕込んでフルテキスト出すようにしました。 記事を content/post から content/posts に移動。Hermit は posts　に記事を書かないとRSSリンクとかが壊れるので。公式にも書かれています。 about記事とかを埋めました。 視野に入っていてやってないのはアクセス解析。 GDPR 対策をつけるのがかなりだるくてつけていません。

ブログのテーマの携帯版が気に入りません。今時はほとんどすべてのテーマが携帯に対応してますが、それがあまりうまくないのです。 気に入らないのは、携帯版の上画面半分を覆うタイトル画像です。多くのテーマが、かなり広い範囲をタイトルにとっています。例えば以下のとおり。 hugoのallegiantというテーマはこの通り。 base16というテーマはこの通り。 どちらも、タイトルが画面の半分以上を占拠しています。特に上のケースはタイトル内の隙間が多いことから、意識的に広範囲を埋めていることがわかります。なんででしょう。すし詰めにしろとは言わないものの、携帯の画面は小さいので、もっと節約して使って欲しいところです。 他のページ作成機であるWordPressやOctopressも似たようなものでした。何かの流行なんでしょうか。 ここまで使われているとすると何か理由がありそうです。ありそうなのは以下の２つ。 横にメニューや装飾を置けない以上、ここでデザインや、あるいは誰のサイトであるかアピールするしかない。 アクセス解析でスクロールを検出している。スクロールしない人は記事を見ていないだろうと。 見たところそういうアクセス解析はついていないので、上の理由でしょうか。スクロールすれば見えるので良い、と。

SMT SolverであるZ3でお絵かきロジックソルバを書きました。練習です。 コードはこちら。 罠が何箇所かありました。まず、Z3 python bindingで多次元配列を作る方法がわからなかったので、１次元配列の添字を適当にスキップさせて二次元の図形用変数を作りました。これは自明。 解答を作ったあと、それを表示しようとしてハマりました。結果の配列をprintするとTrueやFalseが正しく出てくるのですが、それをアスキーアートに変えようとすると全てTrueになってしまいます。原因は以下のとおり。 >>> import z3 >>> q = z3.Bool('q') >>> s = z3.Solver() >>> s.add(z3.Not(q)) >>> s.check() sat >>> m = s.model() >>> m [q = False] >>> m.eval(q) False >>> not m.eval(q) False >>> help(m.eval(q)) Help on instance of BoolRef in module z3: class BoolRef(ExprRef) つまりm.eval(q)の返り値はBoolRefであってBoolではなく、FalseなBoolRefはpythonの真偽値としてはTrueを持つのでした。 ちなみに効率ですが、10x10の人手で解けるパズルを解くのに8秒とかかかります。ちょっとつらい。2^100の探索よりは圧倒的に速いですが、そもそも人手で解くことが可能なパズルならばもっと高速で解けて欲しいところです。不適切なツールだったということでFA。 それからz3で一般に困りそうなところ。そういえば数年前のICFPCでも困りました。 シングルプロセス 遅い時に高速化をどうすればいいかわからない。

新しいことを始めようと何か書いてみます。ブログはありますがfc2で、いまさらfc2もないと思うので放棄して新しい物を作ることにしました。 はやりを探してHugoを採用。公式ドキュメントとコミュニティが充実しているので情報を探すのが楽です。Qiita/tags/Hugoとかに日本語の記事もあります。 やったこと インストール hugo serverでブラウザで読めるようになるまでチュートリアルをこなす。 適当な文章(これ)を書く。 テーマをいろいろ変えてみる。 G+リンクを付けてみる。 fontawesomeを更新してG+のアイコンを正しくする。 一部のテキストを適当に更新。 bitbucketチェックイン。 github pagesに突っ込む。 インストール $ brew install hugo Macだったのでこれで終了。LinuxならGolangと go get で終わりだと思います。 チュートリアル とりあえず公式のドキュメントを読めばよいです。quickstartを追いかけました。あとは適当に読めばよいです。Hosting on GitHub Pagesを読んでさくっとアップロードしてしまっても良いですが、私はそれを少し日和りました。 Install some themesの作業だけ地味に時間がかかります。テーマを全部落としてくるので。 テーマ テーマを選んでサイトのデザインを変えられますが、これがなかなか苦労しました。迷います。あと不適切なやつもアリマス。 テーマはHugo Theme Showcaseから探します。チュートリアルに従うとテーマが一通りインストールされているので、 --themes の引数を変えて実際に試すこともできます。 実際に触るとテーマがいろいろとバグってたりして楽しいです。自分で文章をいくつか書いて試すことをおすすめします。私が見つけたのは以下の様な例です。 プログラム片のスタイルが崩れる。 config.yamlに指定する変数名がtypoしているので、説明通りに設定しても動かない。 トップページの概要が崩れる。 github pages に突っ込む。 Hosting on GitHub Pagesに概要があります。しかし、あんまりよい手順に見えなかったので理解したうえで別の手順で行いました。 上までの手順を行いサイト例を手元に作る。public以下は作らなくて良い。 bitbuket.orgかどこかにgit pushする。 github.comに公開用レポジトリをつくる。ここには公開されるデータのみが入ることになる。 ウェブインターフェスを用いて適当なREADME.mdを置く。 ウェブインターフェスを用いてgh-pagesブランチを作る。 あとは以下のコマンドを実行。 $ git remote add gh-gh-pages git@github.com:gusmachine/tracker.git $ git subtree add --prefix=public gh-gh-pages gh-pages --squash git fetch gh-gh-pages gh-pages warning: no common commits remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), done. From github.com:gusmachine/tracker * branch gh-pages -> FETCH_HEAD * [new branch] gh-pages -> gh-gh-pages/gh-pages Added dir 'public' $ ls public README.md $ git subtree pull --prefix=public gh-gh-pages gh-pages --squash From github.com:gusmachine/tracker * branch gh-pages -> FETCH_HEAD Subtree is already at commit b9beee57b9945c67e1f3848d9c06d74d3e806f6d. これで、レポジトリは次のようになります。 bitbucket.orgにはhugoの元データが入る。 public以下はgithub.comの公開用レポジトリをsubtreeとして持つことになる。git subtree pushで更新できる。 あと上のチュートリアルで疑問に思ったこと。canonifyurls: true は独自ドメインの直下に置くことにするならおそらく不要です。username.github.io/project/ 以下に置くなら必要そうですが。 残った項目 もう少し文章を足して見られるようにする。 画像を足す方法をまじめに見る。 hugo/Image path 画像はどこに置くのか、contentとstatic/imgとで争いが起きてます。とりあえずstatic/imgに設置。Google Photosに置くアイデアは、直リンクの生成が面倒で挫折。 タグの使い方を理解。 faviconを足す。 旧ブログから誘導。 月別アーカイブやカレンダーを足す。 Markdownだとサムネイルとクリックして大きい画像みたいな作業が面倒なので何か考える。