2017-05-14

(ネタバレあり) アイカツスターズ! イリュージョン Show Time 感想

アイカツスターズ! の VR ステージ「アイカツスターズ! イリュージョン Show Time」を何度か見てきた。 http://www.aikatsu.com/stars/event/aikatsustars_illusionshowtime/

A パターンと B パターンの2つがあって、両方とも見た。実際のところ A と B の差分はそこまで大きくはなくて、曲目と順序や MC パートは共通で一部の曲で歌うユニットやコーデが違うという程度。

VR ステージ

VR ステージというのを見るのは初めてで、少し前にプリキュアでもやってるのを知ってたけど、実際に見たのは今回が初めて。メガネをつけずに楽しめる VR ステージがどんなものか期待と不安があったが、実際に見てみるとすごくよく出来ていて感動した。フル CG によるライブはテレビアニメとかアーケードとかで見慣れているわけだけど、VR ステージだと立体感が全然違うというのもあるし、テレビアニメだとカメラワークによってメインだけが映されていたりするものが VR ステージだと本物のライブのときのように常に全体をみわたせてそれぞれのよさがあった。とくに MC パートではキャラクターの背後に影ができていたり、レイが話している間に観客のほうをきょろきょろして落ち着きがないきららがいたり、本物感を感じられた。スポットライトがあたっていないときの挙動にそれぞれのキャラクターの個性が出ているのがよい。

途中にファッション Show Time という撮影 OK のコーナーがあるのでそこでの写真。暗闇の中なのでうまく撮るのがむずかしい…… なんとなく後ろに影があるのがわかると思う。

映像の出来は大満足だったんだけど、あえて不満点を上げるなら前後の移動がほとんど無いことだろうか。キャラクター同士が交差することはあっても、前後の移動が極端に小さいように感じた。技術的制約なのかもしれない。キャラクターが前に出てくるのに合わせて背景等が動くことで前に出てきてる感は出ていたけど。

ライブ

基本的に曲は全部ショートバージョンなんだけど、みんな大好き episode Solo だけがフルバージョンで、フルだとわかった瞬間に自分含めて会場全体でどよめきがおこった体験がよかったですね…… 荒野の奇跡ではステンドグラスが割れるシーンが VR でも再現されていてよかったし、舞っていた羽がラストで空中で停止する演出もかっこよかった。停止するのはアニメ53話ともアーケードとも違うので独自だと思う。

A パターンでは One Step がアニメ31話の SKY-GIRL バージョンで、個人的にはゆずこしょうのユニットが好きではあるんだけどこれはこれでよい。またアニマルカーニバルではゆずとあこのバージョンで始まった後、途中できららが入ってくるという楽しい演出があった。ゆずといいきららといい、スターズになってからポップの自由なアイドルが好きになった。一方 B パターンではアニマルカーニバルがアニメ42話のゆずリリバージョンだった。ありがとうございます。One Step はゆずこしょうバージョン。それ以外の A、B の差分だと、Miracle Force Magic でツバサのコーデが変わっていたり、A ではみつばちのキスがゆめロラで B ではアニメ44話のまひロラバージョンだったり。どちらが好きかが諸説ありそうだけど個人的には A がより好きです。

その他

ライブシーン以外にもニコニコしてしまう場面がいくつかあって、リリィのステージが終わったときに壇上に出てきて甘やかしていくゆずとか、ファッション Show Time での香澄姉妹の掛け合いとか、エルザとかと立っているときららの身長が低めな点が目立ったりとか。それとエンディングで2人ずつペアで登場して締めの挨拶をしていくところは外せなくて、最初いきなりひめツバが手を繋いで登場したときにヒッと声が出たけど、その後ゆずリリ、よぞまひ、あこはる、ゆめロラと全員手を繋いで登場して感謝しかなかった。カプ厨にやさしい。

2017-05-09

分離式キーボード MiSTEL BAROCCO MD600 を使ってみた感想

https://www.amazon.co.jp/dp/B01KN6VEYG/ これを買って3週間ほど仕事とプライベートで使ってみた感想。先に結論を書いておくと、現在は使わなくなってしまった。

きっかけ

Nintendo Switch を発売日に手に入れてゼルダの伝説 BotW を楽しんでいたところ、プロコンのほうがより正確に操作しやすいと感じつつも、左右に分かれた Joy-Con での操作がとても楽であることを実感し、分離式キーボードにも興味を持って MiSTEL BAROCCO MD600 を買ってしばらく使ってみることにした。

前提

Realforce と ThinkPad のワイヤレスキーボードをよく使っていて、単純にキーボードとしては Realforce が一番良いと思いつつも、ThinkPad のトラックポイントとワイヤレス (Bluetooth) も便利だと思って使っている。どちらも物理的には JIS 配列のキーボードであるものの、論理的には US 配列として使っている、いわゆる物理 JIS 論理 US の状態。余った無変換キーとか変換キーとかを Esc や Shift にリマップして使っている。 https://github.com/eagletmt/dotfiles/blob/master/dot.Xmodmap

良かった点

楽な姿勢で使える

そもそもこれを期待して買ったわけだけど、実際に左右に分かれていることでより楽な姿勢で使うことができた。個人的にはこれだけでも結構でかい。左右のキーボードをつなぐ付属の USB ケーブルがやたら短いのが気になったけど……

悪かった点

右手でも左手でも押したいキーがあるのに押せない

自分は b と y のキーを普段は両方とも左手で押しつつもたまに右手で押したりする。左右に分離しているキーボードである以上、右側にあれば常に右手、左側にあれば常に左手で押さなければならない。これが結構きつかった。 y キーを右手で押すように矯正するのはそれほど大変ではなかったけど、普段左手で押してる b キーも時折右手で押していることに気付いて、これらを完全に矯正しきるのはなかなか大変そうだと思った。

物理 US のキーボードである

前提でも書いたけど、普段は無変換キーや変換キーを Esc や Shift にリマップしている環境で生きていて、それらができない時点でストレスがあった。物理 US の環境は仕事で触れる機会もあるので一時的に使う分には問題無いけど、ストレスなく常用できるまではいけなかった……

一部キーが Fn と同時押しである

矢印キーやバッククォート、チルダを押すのに Fn と同時押しで厳しい。物理 US であることにも関連するけど、自由にリマップできるとはいえそもそもキーの数が少なすぎる。

うるさい

メカニカルキーボードうるさい……

まとめ

分離式で、JIS 配列で、左右に y と b キーがある、Realforce がほしい。

2017-05-09

Docker と nftables

Docker は iptables を前提として書かれており、nftables を使っている環境ではそのままだと動かない。 issue は既にあったんだけど nftables を使っている環境はまだまだ少なそうだし進まなそう https://github.com/moby/moby/issues/26824 。とはいえ iptables でやってることは少ないので、ちょっと設定を足せば動かせる。

とりあえず dockerd に iptables を触らせないようにして、

# /etc/systemd/system/docker.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --iptables=false

あとは nftables の設定で masquerade を足せばいい。nftables だと変数使えて便利ですね。

define docker_bridges = {"docker0", "br-0123456789ab"}

table inet filter {
  chain forward {
    type filter hook forward priority 0;
    policy drop;

    ct state {established, related} accept;
    ct state invalid drop;

    iifname $docker_bridges accept;
  }
}

table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0;
  }

  chain postrouting {
    type nat hook postrouting priority 0;
    oifname != $docker_bridges masquerade;
  }
}

Docker の network を作成すると br-${network_id} というブリッジが作成されるので、Docker の network を作成するたびに手動で編集する必要があるのがだるいけど、まぁ network を増やすことはそんなに発生しないはず。

2016-12-31

2016年の思い出

しゃかいじんさんねんめ

去年は http://eagletmt.hateblo.jp/entry/2015/12/31/212651

仕事

hako の開発と環境作りがメインだった。 https://github.com/eagletmt/hako

Docker を使ったアプリケーションの動作環境作りは去年もやってたんだけど、Amazon ECS が出てきたのでそれを利用した環境とそのためのデプロイツールの開発をしていた。開発自体は去年の9月頃から始めていたんだけど、ツール面でもインフラ面でもちゃんと使える状態にして、実際に使われ始めたのが今年だった。社内で新規に Web アプリケーションを作ったりバッチジョブを作ったりする上で標準的な選択肢になってきている。 http://techlife.cookpad.com/entry/2016/03/16/100043

発表

Rails Upgrade Casual Talks に誘われて発表してきた。発表は今年だけど内容的には 2年前のものなのであんまり今年感は無い。 https://speakerdeck.com/eagletmt/activerecord-3-dot-2-4-dot-1

あとは hako の話を JAWS-UG おコンテナ支部 #5 でした。Amazon ECS を使ってこういう環境を用意して、そのために hako というツールを作っているという話。 https://speakerdeck.com/eagletmt/ecs-woli-yong-sitadepuroihuan-jing

趣味開発

envchain の Linux 対応をしたのが自分にとって地味に一番インパクトあった気がする。個人でも仕事でも利用している。

あとは録画スケジューラで試しに gRPC 使ってみたり、mitamae を高速化してみたりかな…… こう書いてみるとあんまコード書いてない気はする。

VPS と自宅の間に Site-To-Site VPN はったり IPv6 対応したりして、ちょっとだけネットワークまわりの経験値をためた。 Docker のネットワークまわりの理解の助けにもなった気がする。iptables に対する苦手意識が減った。

アニメ

アイカツ終わってしまいましたね…… アイカツスターズ、最初はちょっとうーんと思っていたけど、劇場版がすばらしくてそこからテレビシリーズのほうの印象も一気によくなった。毎週楽しみです。

ViVid Strike! が魔法少女感はないもののやっぱりリリカルなのはだこれってかんじの話でとてもよかった。これとあわせてついに Reflection の上映日も発表されて本当に楽しみですね。

BD 買ったのはアイカツ、アイカツスターズ、プリズマイリヤドライ、ViVid Strike!、(まだきてないけど) ブレイブウィッチーズ、と結局代わり映えしないかんじになってた。

ゲーム

星のカービィロボボプラネット、スターフォックスゼロ、世界樹の迷宮5、そしてポケモンサン・ムーンが買って面白かった。あと地味にピクロスにはまってピクロスeのシリーズを買ったりしていた。

ペルソナ5とうたわれるもののために PS4 を買った。PlayStation 系のハードを買ったのはこれが初めて。友人にやらせてもらったり、友人から PSP を借りてなのはのゲームをやったことはあったけど。どちらのゲームもたいへんよかった。

アイカツスターズの筐体デビューしてゲーセンに行く習慣ができた。その結果、最近スクフェス AC をやって楽しんでる。EXTREME まではついていけるけど CHALLENGE はがんばりが必要そう。音ゲー勢からはチュウニズムをすすめられているので来年は。

2016-12-17

mitamae の高速化

itamae と比較して mitamae のメリットをシングルバイナリ以外にも作りたいなと思って mitamae の高速化を進めている。

高速化の方針は「できるだけ Ruby (mruby) のプロセス内で実行する」というもの。 itamae と mitamae の差の一つに SSH サポートや Docker サポートがあって、itamae は SSH 越しに実行したり Docker コンテナに対して実行したりできるが、mitamae はローカルのみをサポートしている。 mitamae では未実装なだけかと思ったが、既に一部の実装がローカル実行前提のようだったので、だったらその前提で外部コマンドを使わずに Ruby でファイルの存在などをチェックすることで高速化できるだろうと考えた。実は itamae のときにも同じことをやろうとしていて実際にちょっとだけ作ってみていたんだけど、うまく itamae 本体に組込む方法が思いつかずにそのまま放置していた。このアイデアを mitamae に実際に実装して、1.2.x 系でいくつか取り込んでもらって高速化されている。

mitamae に入れた高速化は MItamae::InlineBackends という定数の下にクラスを作ると起動時に読み込まれてそれを使って specinfra のコマンドを一部乗っ取れるようにするという形で実現した。 mitamae 本体だけを考えるとちょっとまわりくどい方法だけど、こうすることによって MItamae::InlineBackends::NantokaBackend というクラスを提供する mrbgem を mitamae と一緒にビルドすることで、mrbgem を使って特定の環境に特化した高速化を入れることができる。これを実際にやっているのが mitamae-pacman で、Arch Linux でこれと一緒に mitamae をビルドして使うと pacman -Q のかわりに libalpm*1 の関数を使って高速にインストール済みかどうかの判定ができるようになる。

https://github.com/eagletmt/mitamae-pacman

結果としては、個人で mitamae で管理しているとあるサーバにおいて mitamae v1.1.2 だと dry-run に7.8秒くらいかかっていたものが mitamae v1.2.4 + mitamae-pacman v0.2.0 だと1.2秒くらいになった。これだけ差があると体感でログが流れる速度が変わっているのがわかる。

*1:Arch Linux のパッケージマネージャ pacman のバックエンドとなるライブラリ

2016-12-11

mitamae 向けの itamae-secrets を書いた

構成管理ツールを使う上で悩ましい問題として秘匿値の管理があり、それに対する解決策の一つとして itamae 向けには itamae-secrets というものがあった。自分も秘匿値の管理にこの itamae-secrets を使っていたが、この度 mitamae に移行してみようと思い、mitamae で使える itamae-secrets として mitamae-secrets というものを書いた。

https://github.com/eagletmt/mitamae-secrets

mitamae-secrets の暗号化・復号を実装するためには OpenSSL が必要だが、mruby 向けの OpenSSL バインディングはまだ存在していないようだったので、必要な部分だけ OpenSSL の関数を使いながら C で実装する形にした。 EVP という高レベルの API をそのまま使えたので C 実装部分はわりとすっきり書けた。

mitamae で mitamae-secrets を使うには、まず mitamae を mitamae-secrets と一緒にビルドする必要がある。ここがちょっとめんどくさい点ではある。自分の場合はこういう build_config.rb を用意してビルドした mitamae バイナリを使っている。 https://aur.archlinux.org/cgit/aur.git/tree/?h=mitamae

node[:secrets] = Itamae::Secrets::Store.new(path) と書いていたものを node[:secrets] = MitamaeSecrets::Store.new(path) に変えればだいたいそのまま動くと思う。少なくとも自分の使い方ではそのまま動いている。 itamae-secrets set とか itamae-secrets newkey に使う itamae-secrets コマンドの代わりとなる mitamae-secrets コマンドも用意している。ただし .itamae-secrets.yml を読む機能は現時点ではまだ実装してないので、とりあえず毎回 --base を明示するかんじで……

mitamae 移行の感想

既に itamae を使っているところから mitamae への移行を実際にやってみた感想としては、itamae-secrets 以外の点では Ruby と mruby の標準添付ライブラリの差が地味につらかった。普通に Ruby を使っている itamae では IPAddr とか Digest とかが使えたのに、mitamae では使えない *1 ので、そこを書き直す必要があった。個人の環境なのでそこまで大変ではなかったとはいえ無視できないコストはかかっていて、mitamae に移行するメリットが本当にあるのか今もちょっと疑問だけど、今後メリットを自分でも作っていきたい気持ちでしばらくは mitamae を使っていこうと思っている。とりあえず、外部コマンドを実行しすぎで遅い問題を mitamae で解決していきたい……

*1:それぞれ mrbgem としては mruby-ipaddr や mruby-digest はあります

2016-09-18

IPv6 と Docker と NAT

IPv6 のアドレスが1つしかない状況で、ネットワークが分離されたコンテナから IPv6 で通信しようとすると IPv6 だろうと NAT が必要になる。このへん Docker がどう扱うのかよくわかってなくて、結局 Docker の外側で docker0 とか ip6tables を管理することで動いた……

まず docker0 に使うレンジを決める。ここでは fdbb:3f26:ceda::/48 と 10.11.0.0/16 とする。 docker0 を systemd-networkd で作る。

% cat /etc/systemd/network/docker0.netdev
[NetDev]
Name=docker0
Kind=bridge
% cat /etc/systemd/network/docker0.network
[Match]
Name=docker0

[Network]
Address=10.11.0.1/16
Address=fdbb:3f26:ceda::1/48

dockerd を起動する。このときネットワーク系のオプションを切っておく。

% cat /etc/systemd/system/docker.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --ipv6 --fixed-cidr-v6=fdbb:3f26:ceda::/48 --bridge=docker0 --ip-forward=false --ip-masq=false --iptables=false -H fd://
# systemctl start docker.service

デフォルトだと dockerd が IPv4 でやっていたことを、IPv4 と IPv6 の両方について自分でやる。

% cat /etc/sysctl.d/30-ip-forward.conf
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1

# iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# iptables -A FORWARD -s 10.11.0.0/16 -i docker0 ! -o docker0 -j ACCEPT
# iptables -A POSTROUTING -s 10.11.0.0/16 ! -o docker0 -j MASQUERADE
# ip6tables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# ip6tables -A FORWARD -s fdbb:3f26:ceda::/48 -i docker0 ! -o docker0 -j ACCEPT
# ip6tables -A POSTROUTING -s fdbb:3f26:ceda::/48 ! -o docker0 -j MASQUERADE

これで Docker コンテナ内から IPv6 で通信できるようになる。

% cat Dockerfile
FROM ubuntu:16.04
RUN apt update && apt install -y curl
% docker build -t ubuntu-curl .
% docker run --rm ubuntu-curl curl -sv -o /dev/null https://ipv6.google.com/
*   Trying 2404:6800:4004:816::200e...
* Connected to ipv6.google.com (2404:6800:4004:816::200e) port 443 (#0)
(snip)

ただ、ULA なアドレスを使っているせいで A も AAAA も持っているようなドメインの場合、デフォルトだと IPv4 が優先されてしまう。

% docker run --rm ubuntu-curl curl -sv -o /dev/null https://google.com/
*   Trying 172.217.25.78...
* Connected to google.com (172.217.25.78) port 443 (#0)
(snip)

この優先度は /etc/gai.conf で決められているので、とりあえずそこを変えれば IPv6 が優先されるようになる *1。

% cat gai.conf
label ::1/128       0
label ::/0          1
label 2002::/16     2
label ::/96         3
label ::ffff:0:0/96 4
% docker run -v $PWD/gai.conf:/etc/gai.conf:ro --rm ubuntu-curl curl -sv -o /dev/null https://google.com/
*   Trying 2404:6800:4004:819::200e...
* Connected to google.com (2404:6800:4004:819::200e) port 443 (#0)
(snip)

今回は Docker でやったけど、systemd-nspawn (machinectl) を使うときもやることは同じ。 docker0 と同じ要領で br0 を作って systemd-nspawn --network-bridge=br0 で起動する。 systemd-nspawn の場合は勝手にアドレスを割り当てたりしてくれないので、それはコンテナ内の systemd-netword でやるようにする。このときデフォルトだと host0 に対して余計な設定があるので、コンテナ内で ln -s /dev/null /etc/systemd/network/80-container-host0.network で切っておく。

*1:curl の場合は -6 で IPv6 を強制できるけど