2018年の思い出

しゃかいじんごねんめ

去年は https://eagletmt.hateblo.jp/entry/2017/12/29/001156

仕事

引き続き ECS を中心とした運用関連のことをやっていた。ECS 自体というよりはその周辺がメインで、たとえば docker logs の保存先を S3 にしてみたり、コンテナインスタンスをスポットインスタンスにしてみたり。このへんの話は https://speakerdeck.com/eagletmt/building-a-steady-ecs-infrastructure で話した。

あとはインターンやアルバイト時代からずっと所属していた開発基盤チームが内部的に2つに分かれて お台場プロジェクト を進めるチームとマイクロサービス的な基盤 (ECS とかサービスメッシュとか gRPC とか) をやる2つのチームになり、後者のほうのリード的な役割になった。来年からはまた少し立場が変わるので不安も大きいけどやっていきたいですね。

インフラ

VPS の環境に Kubernetes クラスタを立てて、今まで Kuroko2 で動かしてたものを CronJob にしてみたり、いくつかの雑 Web アプリをデプロイしてみたり、といった構成変更を行ってた。Kubernetes クラスタを立てるの難しすぎて最終的に Arch Linux から Ubuntu に変えてお手軽なセットアップにした……

自宅のマシン用に NVMe SSD を買った。実際に I/O が速くて HDD -> SSD にしたときと同じくらいの感動があった。

アニメ

去年から引き続きほぼ女児アニメしか見てない。プリキュアが新シリーズになるのは毎年のことだけど、プリティーシリーズとアイカツシリーズが同時に新シリーズに切り替わることになって負荷が高かった。アイカツフレンズは世界観が少し初代に戻ったように感じて個人的にはこっちのほうが好き。

魔法少女リリカルなのは Detonation がついに公開され、長年のリリカルなのはシリーズファンにとってはたいへんよい作品だった…… GoD を知ってる側としては紫天一家の扱いとか気になったりはしたけど、Reflection と Detonation だけで見れば整合してるし、何よりこれまで暗に描いてきた高町なのはというキャラクターの本質に迫っているのが最高だった。

ゲーム

Switch、3DS

ドンキーコング トロピカルフリーズは Switch 版も楽しめた。気持ち良い死に覚えゲー。 OCTOPATH TRAVELER を買ったけど途中で飽きた。元々 RPG そんなに好きじゃない自覚はあったけど、やっぱりポケモンとアトラス製以外の RPG はできないっぽい。 世界樹の迷宮 X はとても面白かった。ただ裏ボスはパーティー再編成必須でまぁいいやと思って諦めた。 ペルソナ Q2 は合わなかった…… 第二迷宮のボス戦の手前でやめた。最初は単純なバランス調整不足かなぁと思ってたけど、ゲームシステムレベルで面白くないように感じた。 ピカブイは前情報での印象とは違って思ったよりポケモンっぽくて楽しめた。とはいえやり込むほどではないなと思って四天王突破くらいで終わりとした。

アーケード

相変わらずアイカツの DCD はやってるんですが、個人的に今年の大きな変化の一つはチュウニズムをやり始めたことだと思う。 アイカツの排出が渋すぎて長時間のプレイを強いられるので休憩がてらにアケフェスをやってたんだけど当時の追加曲の譜面がつまらなくて別のゲームを求めていて、元々少しだけプレイしたことがあったのでチュウニズムを何度かやってみているうちにある日突然レベル9の EXPERT 譜面が普通に S でクリアできるようになり、そこから楽しくなってはまっていった。 年内に レート14を達成 し、最終的なレートは 14.02 (MAX 14.04) となった。 あとイロドリミドリのライブにも行った。

アイカツ

アイカツスターズが終わって次のシリーズに切り替わったり歌唱担当が世代交代したりはあるかなと予想していたけど、歌唱担当全員が卒業し歌唱担当という制度自体も廃止されフォトカツも終了するというのは予想外すぎてショックが大きかった。卒業と言いつつ 5th フェスに一部出演したり、来年のランティス祭りにほぼ全員出演したりするけど…… このへんについては色々と思うところがあるけど長くなりそうなのでこれ以上は別の機会に。

各種イベントには引き続き行ってる。今年からというとフレンズに切り替わったタイミングで DCD のほうの大会に行くようになったことだろうか。THE 3RD PLANET×マグレブ 多摩センター店は神。

しかしライブツアー、武道館、5th フェスの全部が今年あったことなんだな…… 来年の後半くらいにはフレンズで大きなイベントができるといいですね。

送り手のコストと受け手のコスト

自分の中でなんとなく納得がいっただけでとくに結論は無い。 そして今年ここに全くエントリを書いてなかったことにいま気付いた。

ふとしたきっかけで発表するのを好む人の気持ちが気になった。その人は発表スライドだけ見ても話の内容が十分に伝わらず、その場のトークと資料が合わさって初めて成り立つような発表をするタイプのように僕には見えた。その人に限らず、こういうタイプの人はまぁ普通によくいると思う。 一方僕は真逆のタイプで、スライドだけを見てもそれなりに伝わるものを作りがちだ。スライドを読み上げてるだけじゃんという意見も目にしたことがあるけど、実際その通りで口頭で発表するよりドキュメントやブログ記事を書いて公開したほうが良いと思っていて、発表というのはまぁ宣伝効果があるとかそれくらいにしか思っていないところはある。

で、なんで自分はそう思ってるんだろうと考えてみると、受け手側が参照するコストをできるだけ下げたいのではないかと思った。ブログ記事で書いた内容は URL で簡単に共有できて、受け手側はまぁ長くても10分とかそれくらいあれば読める。 一方発表の場合、そのイベントに参加してないとそもそも聞けないこともあるし、動画が残っていたとしても見るのに数十分はかかるだろう。発表が素晴らしいものであったとしても気軽には他人と共有できず、自分がその発表から得られたものがあったとしてもそれを他人に伝えるときのコストが大きい。 良い記事は良い発表よりよくスケールする、と表現できるかもしれない。

逆に発表するのが好きな人は何がメリットなんだろうと考えてみて、まず思いついたのはその方が楽ということだった。 もちろん良い発表をするには事前の準備であったり、その場で受け答えできるだけのしっかりした知識であったりが必要なわけだけど、伝えたい情報を誤解なく伝えるのはドキュメントを書くよりも対面で口頭で説明するほうが楽だと思う。 なので送り手側のコストと受け手側のコストのトレードオフを考えたときに、どっちを優先するかが分かれ目なのかなと思った。 送り手側のコストを下げるというと聞こえが悪いかもしれないけど、情報発信が活発になるという点では良いんじゃないかという気はしているし、文章より対面のほうが正確に伝えやすいというのもその通りだと思う。 そう考えると、僕は情報を整理して後からそれだけ見ても必要な背景や情報に辿り着けるような issue を書くことを好むけど、一方で Slack で気楽なやりとりをして進める人や、あるいは対面で話したがる人がいるのも理解が深まってきた。 YouTube で1時間のライブ配信メインでやってる vtuber が多いのは動画編集のコストが低いからで、一方しっかり編集された動画を作ってると1本が短いので他人に勧めやすく、ヒットしたときの伸びがずっと大きい、みたいな話も思い出した。

ここまでは送り手の話だったけど発表というのは送り手だけでなく受け手もいて初めて成り立つもので、じゃあ受け手側は何故高いコストを払ってまでやってくるのかを考えてみると、そこでしか聞けない話があるというケースもありそう *1 だけど、そういうのを抜きに考えてみるとまぁなんか不思議な気がする。 僕は数年前まではアニメのおたくをやっていたけどライブのようなイベントに興味が無くて、でも去年初めて行ったら楽しくて、Blu-ray の映像を見ているときよりその場にいたほうが楽しい何かはある気がする。双方向感? 一体感? ライブ感? このへんはまだうまく言語化できていない。

というわけで、色々話が発散しつつも、受け手側のコストを気にしてそれができるだけ下がってスケールするように自分がコストを払うか、自分が払うコストをそこそこにしてとにかく発信するか、という間のバランス感覚の違いが人それぞれあって、そこから色々な差が生まれるのかなと思った。 この文章だって酒でも飲みながら適当に話していればすぐ終わってしまいそうだし、そのほうが楽しいかもしれないけど、時間をかけて文章にまとめると多くの人に届きやすい。この文章は別に多くの人に届けたいと思ってないけど。 そんなことを今日の昼休憩の間に考えていたのでした。

*1:送り手側が発表を好むタイプで、ドキュメントや記事を書いてくれないので仕方なく行くパターン

2017年の思い出

しゃかいじんよねんめ

去年は http://eagletmt.hateblo.jp/entry/2016/12/31/215421

仕事

相変わらず hako 関係がメインだった。 とはいえ hako 本体の改善はそこまで力を入れてなくて、それを支える社内の基盤の安定化やスケーラビリティの改善や hako-console の開発が今年の大きなトピックだった。 あとは、この規模の Web アプリケーションの作り方みたいなのがなんとなく分かった気になってしまって代わり映えがしないと感じたので、別なこととしてデータ基盤的なところをやってみたいなぁと思っていた。 具体的には こういうの に絡んだことをやってみたくてちょっと話したりしてたんだけど、結局あんまりうまくいかず。

発表

対外的には Rails Developer Meetup で話した https://speakerdeck.com/eagletmt/web-application-development-in-cookpad-2017 だけ。採用イベントとか社内では他にも少し話したけど。 Ruby に対する興味が年々薄れてきていて今年は RubyKaigi すら参加しなかった。

趣味開発

Rust を使ってみたくて https://github.com/eagletmt/idolmap を書いたくらい。もっと細かいのだとこれまで Ruby で書いていたものを Rust に書き直したりはしたけど、とくにこれといって趣味ではコードを書いてないね……

インフラ

経済的な余裕が生まれてきたこともあって、DB は (録画システムのもの以外は) 全部 Google Cloud SQL を使うようにした。アプリケーションサーバはともかく、DB サーバは壊れたときの消耗が半端なくて、Cloud SQL 高いけど金で解決したい気持ちが強くてそうした。 ストレージサーバも同様で、これまで WD Red を買って保存していたものもどんどん Google Cloud Storage へアップロードするようにしている。

あとはずっと使い続けている ISP の So-net が IPoE の宣伝をしてきたのを始めとして、IPoE に切り替えたり光コラボに切り替えたりその上で何かのオプション *1 を追加したりしたら、IPv6 で Google Cloud Storage への上りが安定して70 - 80MB/s くらいでる環境になってとても快適になった。 それとあわせて DS-Lite で IPv4 でも安定して速度の出る環境になった。

アニメ

ついに最終的にアイドルタイムプリパラとアイカツスターズしか見なくなっていた……

アニメ映画も含めると今年は魔法少女リリカルなのは Reflection がついに公開されましたね!! まさか前編だとは思ってなかったけど!!! 初日に見に行って劇場に入る直前に Reflection と同じビジュアルで Detonation を宣伝するポスターを見た人の気持ちを考えてほしい。 Reflection の内容はちゃんとよかったです。Detonation でちゃんと話を一区切りつけてくれる前提ですが。Detonation ではマテリアルズの出番が増えてほしい。 Reflection が完全に GoD ベースだったので、2017年にもなって PSP と GoD を探して買ってプレイしていた。ハートブレイクマトリクスを劇場で見たい。

ゲーム

Nintendo Switch のおかげでだいぶやった。Switch とゼルダの伝説 BotW は発売前から予約していたけど結果的に大勝利だった。最近になってようやく普通に Switch を手に入れられるようになったらしいけど、なんで発売前から予約してないんですか?? とマウントをとっていた。 Switch ではゼルダの伝説 BotW、Splatoon 2、スーパーマリオオデッセイと順調にプレイしていた。Switch のコントローラが左右に分かれているのも (カジュアル用途では) 非常に動かしやすくてよかった。 Switch 以外だと 3DS で FE Echoes、ウルトラサン・ムーン、真・女神転生 DEEP STRANGE JOURNEY をやった。DSJ についてはまだ最後までいってなくてやってる最中だけど。 来年の Switch のソフトも色々出そうで楽しみ。

アイカツスターズをきっかけとしてゲーセンに行く習慣ができたわけだけど、アケフェスは相変わらずちょいちょいやってる。最近だと Listen to my heart!! がフルコンできて喜んでた程度の実力だけど。未だに Aqours に馴染めてない身としては μ’ｓ の曲を聞きながら遊べるだけで幸福度が高い……

アイカツ

独立したセクションにしてしまったけど今年は Nintendo Switch に並んで個人的にはアイカツの年だった。 ミュージックフェスタ2017でほぼ初めてライブに行ってみたら楽しかったのを皮切りに、様々なミニライブやイベントに行くようになったし、今年は5周年記念ということもあって色々なイベントがあったのでできるだけ参加していた。 ラゾーナ川崎に行ったりラクーアに行ったり、DMM VR THEATER での公演に何度も行ったり、オールナイト上映でバルト9に行ったり、札幌でのアニ ON に旅行を合わせて行ったり、富士急ハイランドに行ったり。 どれも楽しくて本当にありがとうアイカツという気持ちと、これまでの数年間の (とくにスターズになる前の無印の) イベントに参加してなくて非常にもったいないことをしたという後悔があった。テレビアニメはずっと見続けてたんだけどね。 去年の終盤から始めた筐体のほうにもずっと通い続けていて合計でいくら注ぎ込んだのかよくわからない。でもソシャゲよりはマシだと思う(?)。 気付けばもう来週末からライブツアーでそちらもとても楽しみです。

*1:電話でのやりとりだったので詳細を覚えてない

ISUCON7 予選を通過した

ISUCON7 予選に†空中庭園†《ガーデンプレイス》として @ryot_a_rai、@mozamimy と参加して2日目1位で通過することができた http://isucon.net/archives/50956331.html 。

リポジトリは https://github.com/ryotarai/isucon7q

当日まで

例年 Ruby で参加していたけど、今年は発表された初期実装に Ruby が含まれていなかったこと (※後から追加された) もあり、@ryot_a_rai から Go で参加したいという話が出て Go を選択した。 僕と @mozamimy は Go はまぁまぁ書いたことはあるくらいの状態だったので、事前に一度 Go で練習したり pprof の使い方を教えてもらったりしていた。

Go は個人的にはあんまり好きになれなかった言語ではあるんだけど、ISUCON で使う上では普通に書けば普通に速くなるし、 制限時間があってプレッシャーが高い状況で typo とか型エラーとかのつまらないミスをコンパイル時に検出できるので、Ruby よりやりやすく感じた。 おかげでアプリケーションの改修中にほとんどバグを出さずに進めることができた。

当日

僕は主にアプリケーション側の改修を担当していて、MySQL の設定とか Redis をインストールして使える状態にするとか、deploy.sh を用意して git pull && make && systemctl restart && nginx のログローテートを自動化したりとか、そのへんは他の二人に任せていた。 以下、各サーバは isu1、isu2、isu3 と呼ぶことにする。初期状態で nginx とアプリが動いていたのが isu1 と isu2 で、MySQL が動いていたのが isu3。

とりあえずベンチマークを実行してアクセスログを見て GET /icons/:file_name が遅いことがわかり、コードを読むと MySQL に画像を入れてることがわかったので、社内 ISUCON でも見たな～と思いながらとりあえず Redis に入れることにした。 この時点では MySQL の負荷が高かったので Redis は isu2 に入れた。 これで速くはなったんだけどそれでもまだ icons が支配的で、 :file_name が画像の SHA1 値になっていてパスをキーにしてキャッシュできるので nginx の proxy_cache を使ってキャッシュを入れてみたもののほとんど改善せず。 CPU もメモリも余ってるのになんでこんなにスコアが出ないんだ? というあたりで public 側の帯域によるものだと気付いた。 isu1 と isu2 の両方をベンチマーク対象にしたらスコアは伸びたが、それでもリソースは余っていた。 これをなんとかするには画像を配信しないようにするしかなくて、いつかの ISUCON で見たように Cache-Control なのか?? となっていた。 レギュレーションに 304 のケースに関して明確に記述されていて、スコアが100分の1になってしまうものの帯域で詰まってる以上この先に進むには 304 を返せるようにするしかないと決めて試すことにした。 最初は Last-Modified と ETag をアプリケーション側で返すようにして tcpdump をしながら様子を見ていたけど If-Modified-Since や If-None-Match が icons に対して送られてこなくてうーん? と思いながら Cache-Control も返すようにしたら挙動が変わって 304 を返せるようになって一気にスコアが伸びた。 この時点で 16:15 くらいで 98840 点だった。

icons の壁を越えると MySQL や Redis がボトルネックになってきて、ここからは N+1 クエリを直すとか、Redis に移せるものは Redis に移すとか、select のカラムを絞るとか、いつもの作業になった。 MySQL のテーブル定義は変えてない気がする? そのへんは任せていたのでよくわかっていない。 微妙に JS や CSS のリクエストでエラーになっていたので、gzip_static on にしたり Cache-Control 系のヘッダを返すようにしたりしていた。 一通りやりきると MySQL や Redis が空いてきてアプリケーションの CPU 負荷がボトルネックになってきたので、Redis を isu2 から isu3 に移したりしていた。 isu1 と isu2 は nginx とアプリが動いていて、isu3 は public 側の帯域確保のために nginx が動いていてベンチマーカからのリクエストを isu1 と isu2 にプロキシしつつ、Redis と MySQL が動いている状態。

最後に Redis の負荷を分散させるために3台に Redis を入れてシャーディングするというのをやっていた。均等にばらけるのか不安だったけど id を3で割ったり icons のハッシュ値を適当に数値化して3で割ったりして接続先の Redis を切り替えるようにした。 MGET とか HMGET を使っている箇所が面倒だったので、そこは3台に同じクエリを投げてからその結果をマージするようなコードを書いた。 いま振り返るとちゃんと必要なキーだけ集めてクエリを投げるように直してもよかったな。 isu3 だけアプリが動いてなくて CPU 負荷が若干低かったので isu3 にウェイトを置くようにして比率を調整したりもしてみたが、あまり効果もなさそうだったので 1:1:2 の比率で決定にした。 このへんでコードフリーズということにして、pprof の削除やロギングの削除をやった。

ラスト1時間で再起動試験と最終スコアの確定をやった。レギュレーションでは最後のスコアが使われることになっており、今回のベンチマークは同じコードで実行しても一割くらいスコアにぶれがあることがわかっていたので、ここまでのベストスコアが59万点だったため58万点以上が出たらそれを最終スコアにしようという風に決めてベンチマークを実行した。 実際には再起動後のベンチマーク一発目で58万点が出たので、もう少し試したい気持ちもありつつも、最終的にはこのときのスコアのまま終えた。

感想

icons の 304 をさっさと試して最初の帯域の問題を早くクリアできたのが大きかったかなと思う。画像をファイルシステムに置いて nginx に任せるとかせずすべてアプリケーション側で扱うようにした結果、Last-Modified や ETag のずれではまるのも意図せず回避できていた。 アプリケーションの改修でバグを出さなかったのも調子がよくて、最後のシャーディングも一発でベンチマークが通って気持ちよかった (スコアはそこまで伸びなかったけど)。 予選から3台のサーバを使う問題で、ベンチマーク対象を複数指定できるという新鮮な設定で楽しめました。ベンチマークもエンキューしたらすぐに実行されるような環境で体験がよかった。 本選でもよいスコアを残したい。

present? と blank? が嫌い

params の中身のように入っているオブジェクトのクラスが事前に分からないものに対して空っぽい文字列の場合と存在しない場合を区別したくないときに限って blank? を使うのは分かるけど、 nil チェックをするために blank? を使ったり、配列が空かどうかをチェックしたいだけなのに blank? を使ったりすると、 blank? の挙動を正確に理解して nil と空配列を区別したくないから使っているのか、それとも nil がくるかどうか分からないので適当に防御的に blank? を使っているのか、 あるいは blank? しか知らないのかが読みとれずにめんどくさいと思うことがよくある。 かわりに empty? を使っていれば empty? を持っているオブジェクトは blank? を持っているオブジェクトより少ないので読み手に伝わる情報量が大きくなるし、 かわりに nil? を使っていればその変数や引数が nil かもしれないことが考慮されているということが伝わりやすい。 blank? を気軽に使う人たちは ' '.blank? や '　'.blank? の結果を知って使ってるのかも気になる。 これらを知った上で blank? が適切だと判断し blank? を使ってるならいいけど、そうは思えないようなコードをよく見る。

似たような理由でブロック無しの any? が嫌いで、 !ary.empty? のかわりに ary.any? と書く人たちがいるけど、[nil].any? や [false].any? の結果を知った上でその挙動を意図して書いているのか、単に ! と empty? を書くのがめんどくさくてそうしているのかが読みとりにくい。

Rails アプリでオンラインでカラムの削除やリネームを行うには

前提知識

Rails アプリにおいて、テーブルの追加やカラムの追加は簡単なものの、カラムの削除やリネームは慎重に行う必要がある。たとえアプリからそのカラムを参照してないとしても、いきなりカラムを削除するとエラーになる可能性が大いにある。

というのも Rails にはスキーマキャッシュというものがあり、テーブルのカラム情報をモデルがキャッシュしているからだ。このキャッシュはたとえばいわゆる N+1 クエリ問題を避けるために includes (eager_load) するときに参照される。 SELECT 句で t0_r0 のような機械的に別名が振られるようなクエリを見たことがある Rails エンジニアは多いと思う。

機械的に全カラムを取得するためにスキーマキャッシュを利用しているため、このようなクエリが実行されてる中でカラムを削除したりリネームしたりすると、スキーマキャッシュをもとに並べらたカラムの一部が消えてしまうため、不正なクエリとなってエラーになってしまう。 このせいで Rails においてカラムの削除やリネームは面倒なものになっている。

Rails 5.x 以降のやりかた

Rails 5.0 からは ignored_columns というオプションが追加され、ここに追加されたカラムは Rails からは見えなくなる。 このオプションはまさに Rails のオンラインスキーマ変更のやりにくさを解消するために追加された。僕が Rails 5.0 で最も好きな改善の一つだ。

https://github.com/rails/rails/pull/21720

なのでカラム削除の手順としては、

  1. アプリケーションコード内でそのカラムを参照している箇所を直す (これはスキーマキャッシュとは無関係に当然やる必要がある)
  2. Model.ignored_columns にカラム名を追加してデプロイ (1と同時でもよい)
  3. 実際にカラムを削除またはリネーム
  4. Model.ignored_columns を元に戻してデプロイ

という流れになる。

Rails 4.x でのやりかた

ignored_columns は使えないが、DB からカラム情報を取得するところにモンキーパッチをあてて特定のカラムを隠すようにすればなんとかいける。 具体的には MySQL を使っている場合は mysql2 adapter のメソッドをフックする。

module ActiveRecordInvisibleColumn
  INVISIBLE_COLUMNS = {
    'foos' => ['bar'],
  }.freeze
  def columns(table_name)
    super.delete_if { |column| INVISIBLE_COLUMNS.fetch(table_name, []).include?(column.name) }
  end
end

ActiveSupport.on_load :active_record do
  ActiveRecord::ConnectionAdapters::Mysql2Adapter.prepend(ActiveRecordInvisibleColumn)
end

この方法は foos というテーブル名が (たとえ複数の DB を使っていても) グローバルに一意という前提を置いている点に注意する必要がある。 これで Rails 5.x の ignored_columns と同じような効果が得られるので、あとは同じ流れでカラムの削除を進めることができる。 過去に某巨大 Rails アプリで実際に成功したのでまぁたぶんだいたいいけると思う。

とはいえ Rails 5.0 以上にさっさとバージョンアップして ignored_columns を使ったほうがいいことは言うまでもない。

(ネタバレあり) 魔法少女リリカルなのは Reflection 初日感想

文章にまとめられなかったので箇条書きで。

  • まず劇場に入る直前に Detonation が 2018 年公開という掲示を見て戸惑う。そこに映ってるなのはの姿は Reflection と一緒だし、キャスト一覧を見ても変わってないし、つまり……? という気持ちで入場した
  • はやてが自分の足で走ってる姿にまず感動。立って歩いてる姿は 2nd A’s にもあったけど、こう普通に生活できてるんだな感が
  • 今までは海鳴市という架空の場所だったのに、急に東京とか新宿とかが出てきて驚いた。これ今までのなのはシリーズの中で結構大きな変化な気がするけど……?
  • 咄嗟にワイヤーで反撃するのがとてもなのはらしくてよかった。強い
  • キリエがなのはやフェイトの顔面を全力で殴ってて笑った。実質 Vivid Strike!
  • リインがキリエに抵抗しているのがかわいかったし、キリエもちゃんと手加減していて傷付けることが目的ではないことを表せていてよかった
  • なのはが今度こそ助けると決意している横顔をアリサが心配しているシーン…… ここが実になのはらしくアリサらしく、今回の映画の中で特に好きなシーンの一つ
  • 闇の書事件を回想するときに「2年前」と言われていて実際作中だとそうなんだけど、こっちは5年待ったよ!!という気持ちで見ていた
  • シャーリー出てくるの意外すぎた
  • マテリアルズの登場。紫天一家大好きなので事前情報で登場が分かった時点で喜んだし劇場アニメで動いている姿を見れて感謝……
  • なのは対シュテル、高火力の魔法のぶつかり合いは見ていて楽しい。そういえばこのときってレイハさん無しで戦ってた?
  • ユーノくんの結界強すぎる
  • フェイト対レヴィは、フェイトの最後の必殺技ですね…… バインドをかけて全力全開といいながら撃つ姿は 1st のなのはのそれでここも特に好きなシーン
  • リンディを母さんと呼ぶシーンはとても感動的なんだけど、バインドをかけられてるとはいえレヴィがすぐ近くにいることを思うとちょっと
  • はやて、基本後方支援型なので全体的に得意分野じゃない戦闘で苦戦したり変身シーンもカットされたりでやや不遇だった……
  • イリスが嘘を告白するシーン。全部が嘘ってのもちょっと無理があると感じたし Detonation で回収されてほしい
  • そしてユーリ登場。一応 BoA や GoD のストーリーを知ってる身としては特に設定が変わったように見えたけど、とはいえ Reflection の時点では情報が少なすぎてなんとも。個人的にはイリスが言ってる内容には一部間違いというか勘違いみたいなのが含まれていると思っているけど、どうなるんでしょうね
  • なのはが立ち向かおうとしたところで終わり。入場前に見た Detonation の掲示と合わせて、前後編か～～という気持ちになった
  • 最後の週変わりの映像特典、マテリアルズがメインでしゃべってるだけで嬉しいし、来週は初代リインフォースも出るっぽいので楽しみですね