幸せな夢と夜明け
最近は増田以外でもアイマスやめましたという記事が出てきて、それまでに増田で散見されていたものも含め、P廃業エントリにはそれぞれ違った味わいがあり良いことだなぁと思っています。薬物、宗教、呪い、いろいろな言葉で表現されるこのコンテンツですが、私は「今は」幸せな夢であると考えています。そして、そのような夢から覚めた人たちが綴る文章に、いつか自分が夢から覚めるときのことをぼんやりと考えるのでした。
一方でそれらの記事って何か怨嗟というか、後悔や呪詛や愚痴みたいなものが底で渦巻いているようで、なぜ文章からそういう印象を感じるのか、あんまり言葉にできなくてモヤモヤとした気持ちもありました。今回ブックマークしておいた記事を読み返していくと少しだけ見えてきたものがあったので、殴り書きのメモとして残しておきます。
推してるアイドルの最高レアのカードを引けなかったから担当とは言えないと苦悩する同僚、私のことをPとして慕ってるはずのアイドルはこんなことしないと言って抱いたイメージと折り合いが付かなくなる同僚。いろいろいました。"元"同僚たちはおそらく、アイドル達に対する愛情の証明に行き詰まっているんじゃないかと思いました。別にレアカードを持たなくてもアイドル達は私たちを慕うでしょうし、壁ドンされたままゆはあなたのことが嫌いとは言っていない。でも、元同僚達はそれに納得できなかったわけです。
アイマスのアイドル達（声優とかではなく、コンテンツとしての彼女ら）に限らず、この手のコンテンツでどうしても埋められない距離感があると思っていて、大まかに2つの特徴があると思っています。
- アイドルたちは私たちに好きとは言ってくれない。愛されているという納得を自分でする必要がある。
- アイドルたちは私たちを振ってくれない。私たちはいつだって自分から勝手に振られる。
「自分から振られる」とは何なのでしょうか。それは「愛されているという納得感が失われた」ことであり、その納得感となるものは課金なりレアカードの保有でもCDでも相手に抱くイメージでも何でもありではあるものの「自分で決めた愛情の証明」であるのだから、折り合いがつかずに行き詰まるというのは「自分で自分に幻滅している」と表現することもできるでしょう。
彼らが薬物や宗教や呪い、という言葉でP業務を締めくくるのは「それらにどっぷりハマっていた自分に対して幻滅している」ということでもあるんじゃないかと思います。彼らに取ってのアイマスというコンテンツは、それこそ薬物や呪術でもやっているような悪夢や幻覚になってしまい、もはや幸せな夢ではなかったのでしょう。
もうひとつ。それらのエントリって「アイマス辞めます」の後が書いてないことが多いんですよね。直近のはてなブログの彼（？）はどうやらFGOにどっぷりハマっているようですが、そのような次の夢の話だったり、あるいは続いていく現実のことが記事自体にはほとんど書かれていないのです。「今は元気に荒野や島でAKMぶっ放してます」とか書いてあると、中の人の継続性が感じられていいんですけどね。冒頭で私が「廃業エントリ」と表現したのも、ここら辺の転職感の無さを無意識に反映しちゃってるのかもしれません。
そして、そのような夢から覚めた人たちが綴る文章に、いつか自分が夢から覚めるときのことをぼんやりと考えてしまうのです。私が目覚めたとき、続いていくのが日常なのか次の夢の中なのかは分かりませんが、その時「幸せな夢の続き」を過ごしているのでしょうか。少しだけ、気になります。
追記 2018/01/31 22:39
あ、そうそう、上で言及したエントリの城ヶ崎美嘉と赤城みりあの関係性については、特に美嘉が小さい子好きとかみりあがママとかそういう文脈は無いと思っていて、お互いが姉という同じ立場であるうえで、互いに与えて「姉であることに疲れたら背中を預けられる仲間」という関係性になったのではなかったかなーと思っています。長子って言葉に出来ないプレッシャーがあるからね。デレマスアニメの17話まで見ると良いと思います。
勇気のバトン
これはけものフレンズのアニメシリーズ全体の感想と考えたことである。全話先に見ておくことをお勧めする。アニメ全体としてフレンズの動きや言葉、それによってかばんちゃんにもたらされる影響がよく目につくが、本エントリでは逆に、かばんちゃんがフレンズ達に与えたものは何かを考えてみたい。
フレンズ化してもけもの
重要なポイントの一つとして「フレンズはヒトの形をしているが、それが極度に生活の変化を来していない」というポイントが挙げられる。鳥のフレンズは基本的に飛んで移動しているし、着ている服を認識していない。カバはさらっと泳げないことを明かしている。ジャパリまん等の配給を除いて外部から干渉しないことで元の動物としての生活様式を維持されているように思う。発展して、元の動物としての生活様式を崩さないことで「自分の力で生きること」を維持していると考えることもできる。できるできないを明確に取捨選択して伸ばすという戦略は、実に動物（けもの）のようである。彼女らの軸足はやはりけもの側にあり、それらは「フレンズによって得意なことは違うから」というあるがままを受け入れる言葉によって強調される。もちろん、その言葉や姿勢が当初のかばんちゃんを救ったのは言うまでもない。
ヒトというけもの
もう一つのポイントとして、俗に「英知の時間」と呼ばれるかばんちゃんの活躍シーンがあるが、一旦人類史的な観点を排除して、自分自身の得意を増やし、不得意を克服する、能力獲得のプロセスと捉えたい。崖の移動が困難だったり、川を跳躍できなかったときなどに、かばんちゃんは何度も「ごめんなさい」を口にする。それは「できなければならないことである/であった」という自己認識から出ている（例えば、ジャパリバスのトレーラーヘッドが運べないなど、突拍子もないことで謝ったりはしないだろう）と考えられる。出来そうなのにできないことを良くないことだと思い、それを解決しようとするというかばんちゃんの行動指針は、あるがままを受け入れるけもの達とは一線を画す。 その行動結果として「かばんちゃんはすっごいんだよ、なんでも思いつくんだ」と褒めるフレンズもいれば「あなた、変わった子ね。でも、サーバルを助けようとしたのね」と、変わっていると評価するフレンズもいる。道中で木登りはどんどん上手になり、ついには飛んで走って泳ぐことで窮地のサーバルを助けることになる。
フレンズが"ヒト"を得るということ
ヒトが変わっていく様を見たフレンズ達は、元の動物では考えられないような行動を取るようになる。「サーバル任せじゃダメよ」「基本逃げるのよ」と言っていたカバがかばんちゃんの援護をするなど、小さな変化は1話にも起こっている。最終話では、逃げる相手としていたセルリアンに対して集まって立ち向かった。多種で協力し合うということ自体もけものだった頃ではありえなかっただろう。持てる武器を駆使してぶつかったり、分担して落とし穴を仕掛けたり、あるいは知識を使って足止めしたりなど、戦闘風景も実にヒトのようであった。これは、以前のエピソードでかばんちゃんに感化されていなければなし得ないものだったのでは無いだろうか。そしてサーバルはかばんちゃんのためにできることを自分で考え、ついには火の恐怖すらも克服したのである。
結論
自分や状況を変えることで困難を打開しようと思う気持ちは、かばんちゃんから出会ったフレンズ達に伝わったのである。このような気持ちを、ヒトの言葉では「勇気」と呼ぶ。今回は、かばんちゃんがフレンズ達に渡した勇気のバトンが返ってくる、という観点から全体構成の説明の余地を考えてみた。
Nintendo Switch周辺環境
はじめに
- 2017-07-13 : じわじわ PV 伸びててみんな気になっているな、と感じたので、使っているデバイスや接続形態にについて詳細な情報を追記。
実現したいこと
ざっくり説明すると、ボイスチャットをしながらゲームをプレイしたい。その上で録画配信できるような環境を整えたい。ぶっちゃけると Splatoon2 のためである。
- ゲームプレイは TV モードで、ディスプレイに流したいのは映像のみである。
- ゲーム配信向けに、HDMI キャプチャデバイスで音声+映像を取り込む必要がある。
- ボイスチャットの通話をしながらプレイするために、ミキサーに音声信号を入力する。
実験から分かった前提
- Switch を TV モードにした時、本体のミニジャックから音声を出すと、無視できないレベルでノイズが発生する
- Switch を TV モードにした時、本体のミニジャックから音声を出すと、 HDMI から音声信号が出力されなくなる
以上から、上記の実現したいことが WiiU で可能な「ミニジャックから音声を出しつつ HDMI は単純にスプリッタで分配する」という手段での解決は不可能になった。
機能要件
- HDMI を音声込みで分配しつつ、音声を分離してミキサーに入力する手段
考えた全体構成
買ったもの
そんなに都合がいい HDMI 分配デバイスがあるのかと思ったら、あった。
画像だと2段重ねで1モジュールに見えるが、実際に来るのは1段分で、画像は表裏それぞれの見た目を見せるための2段重ねだった。 2分配した HDMI 出力、 RCA の全てにソースの音声を流せる。クセがあって、ちょっとした切っ掛けで全出力から音声信号が出て来なくなったりするけど、電源を入れなおしたりケーブル抜き差しでなおる。
ミキサー
ミキサー何使ってるの問題がけっこう気になっている人を周囲でよく見るので追記。HDMIから分離した音声をPCのボイスチャットと混ぜてヘッドフォンに送るために使う。
入力はステレオRCA+6.3mmモノラルジャックx4、モノラルジャック側はパンポットとボリュームがついているので、2系統をステレオ1系統と見なすことができ、実質ステレオ3系統まで混ぜられる。
ケーブル類
LINE IN/OUT 系統をメインで使う系統にした方がよい(マイク入力だと機器のアンプを通すのでノイズが乗りやすい)
- PCのLINE OUT(3.5mmステレオピンプラグ) -> ミキサー LINE IN(RCA)
この手の、ステレオ1系統からモノラル2系統に分岐するケーブルは「Yケーブル」と呼ばれているらしい。両端のプラグ形状込みでググるともっと安いのがあるかもしれない。
こんな感じで接続している。どうせここら辺の品質を上げても機器のグレード的にあまりうまみはないし、ケーブルは断線するものであると思って安いのを更新し続けるのがいい。 Amazon Basic 辺りで Dash ボタンとともに登場してほしい。
ES2015強化月間
特にそういうつもりはなかったのだが、6月はめちゃくちゃ ES2015 書いてた。
作ったやつ
細かいものを作っては壊してを繰り返してた中でそれなりに満足したやつを出す
Chromeプラグイン
50分くらいでさくっと書いた、URLに紐づけてノートが書けるやつ。
ブコメみたいに使えるし保存はローカルだから他人には見えない。
リポジトリはこれ。
babel + React で書いてて、 EventEmitter を必要最低限にラップした Store を作って、Store からコンポーネントツリーに直接全 state を流し込むようにしたオレオレ flux にした。これにより
- コンポーネントは state の書き戻し操作に関与せず、与えられた state / props から VDOM を吐く map 操作となる
- 上記に関連して、 state の書き換え処理を一ヶ所に集約できる
- そもそもの構造として、完成品の state をプッシュし続けるだけで良くなる
みたいな点が良さそうだった。
スペクトラムアナライザのデモ
6時間くらいかかった。これも babel + React +Rx 。モチベーションは、
- 音源を Observable ベースのローダーを作って読み込みたかった
- 画面更新の tick 処理も Observable から定期的に実行したかった
- Web Audio API のラッパー作りたかった
- React で SVG レンダリングしてみたかった
という感じだ。おおむね満足している。 SVG上のクリック座標の取得が、(おそらく)グローバル座標系からの差分計算になったりしてコンポーネントのモジュラリティを破壊しかけたり、Web Audio API が FFT の結果を返すとき、周波数を均等割して返すため、一般的に良くあるスペクトラムアナライザのように表示するために対数ベースに変換するなどのドメイン知識の部分で苦労したりでもう二度とやりたくない感じだった。
ES以外
- Knife Solo → Knife Zero (できることできないことがわかってきてやっと実用できそうになった)
- Capistrano2 → Capistrano3 (できることできないことがわかってきてやっと実用できそうになった)
- netty4 でwebsocket のサーバー実装する ( WebRTC のシグナリングに使いたかった)
みたいな感じで、レガシーになりかけてた環境の刷新に向けて動けそうなところまで来た。
この先
まず痩せる。あと右手首が壊れたっぽい(曲げに加えて引っぱりに対して痛みが出るので靭帯の可能性がある)ので適切な対処をする。必然的にイカとかFPSの頻度を下げざるを得ないかもしれない。
激安クソVPSとプロビジョニングツール
クソVPSの話
少し前まではいろいろな怪しい VPS サービスに突っ込んで、サービス改悪や閉鎖などの地雷を踏みまくってるクソ VPS ハンターだったのだが、 CloudAtCost という激安 VPS サービスがあり、半年ほど使い続けている。
この VPS サービスは、基本的に異常に安いという特徴を持っている。1コア0.5Gのメモリで35ドル、CPUとメモリ増やすごとにほぼ比例して料金が上がるのだが、これは月額ではなく払いきりである。一度料金を支払えばサービスか自分が死ぬまでは無限に使えるのだ。さらに言うと、表示されている価格に対して、ほぼ常時4割引のセールを行っており、たまに6-10割引のクーポンを Twitter やサイト上で配っている。
なぜこんなに安いかという疑問はある。FAQ - How can you do this for this price?にある程度説明があって
- ネットワークは国営インフラと提携
- 電気代が安い
- データセンターの用地やハードウェアを既に調達済み
らしい。日本とはだいぶ事情が違うらしいが、良くわからない。
購入するのはインスタンスではなくサーバープランであることも大きな特徴だ。契約したプランの範囲内で、自由にインスタンスを立ち上げることができる。たとえば、4コアのプランを2つ契約すれば
- 8コア x 1
- 2コア + 6コア
- 2コア x 4
などの分配が可能だ。メモリやストレージについても、同様に分配可能である。
ここまでだと非常に良い印象だが、そこまで旨い話はやはりないのだ。
良くないところとして
- CPU がしょぼい(6年くらい前のやつ)
- CPU / 回線帯域の継続的な使いすぎで無断停止する可能性がある
- 初期設定だと7日で止まる罠がある
- インスタンスの生成が遅い、失敗する可能性がある
- インスタンスに IP がアタッチされても、外からアクセス可能になるまでが遅い
- 遅いだけなら良いがいつまでもネットワークからアクセスできない場合もある
- IP を静的にアタッチする( AWS だと EIP みたいな)機能がない
- ping が遅い(RTT が 160-200ms 程度)
という点が挙がる。インスタンスが正常にセットアップされ、ネットワークに繋がるという当たり前のことに、低くはない一定の確率で失敗し、その後も常に突然死し得るという要素は、クラウドサービスを標榜するものとして大変なマイナスである。そして何よりまずいのは、
というところである。極めて厳しい。
さて、この「RTT が長くレスポンスが悪い、いつ吹っ飛ぶか分からない」というサービスをいかに使っていくかというところで、サーバーのプロビジョニングツールの出番となる。
プロビジョニングツールの話
chef などのプロビジョニングツールの良いところは
- あるべき状態を記述すれば自動的にパッチを当ててその状態にする
- 羃等性の担保(いつでも何回でも同じ作業を繰り返すことができる)
ということで、これはサーバー内の state (ログとか保存の必要性があるファイル)さえ管理しておけば、いつでもそのサーバーを使い捨てにできる (disposable) という事である。逆に言えば、state なんて捨ててもいいという使い方に限定すれば、人間がやることはどうあるべきか、という完成形を記述して push するだけでよいのである。 ssh でログインしてミドルの設定ファイルを手で弄ったりする作業を jQuery 的と例えるならば、プロビジョニングツールのアプローチは仮想 DOM に近いものだろう。
クソ VPS サービスの歩き方
というわけで、いつ dispose されるか分からないクソ VPS では
- state を捨てても良い使い方しかしない (サーバーを disposable にする)
- そのための手段がプロビジョニングツール
というのが今の自分の考え方だ。実際、本当にどうでも良いインスタンスを除く、webやゲームサーバーのホストなどは chef のレシピを書いて管理している。コンテンツに付いても、消えたら困るものに付いては github で管理しつつ、それを使うサーバーが fetch するようにしている。
回線が細かったり CPU がしょぼかったりするので、おすすめの使い方は
- 時間かかっても良いような定期ジョブやCIを回す
- クローラ(通信遅くても別に良い)
- Webサーバーにするけど無料のCDNで高速化する
- ゲームサーバーとかならCPUをたくさん割り当てて、CPUバウンドな処理でも使用率が上がらないようにする
くらいだろうか。どのみちあまり信用していないので、復旧可能にできない、かつクリティカルな用途には使わない方が良い。仕事で使うとかありえない。
React勉強会1(2016-05-25)
発端
やりたいと言ったら @mizchi がやってくれることになった。
今回の目標
メインクエスト : この json を使って、Splatoon のブキを一覧表示する機能を作る
サブクエスト : 絞り込み機能を付ける
サブクエスト : 検索フォームと一覧部分をサブコンポーネントに分けて、それらを管理するルートコンポーネントに state の更新内容を書き戻す
進捗
割と実践的で、構築しながら説明と言う感じだった。実際 GitHub - dolpen/react-tutorial のコミットログを見た方が何をしたかは分かりやすいのではないかと思うので大胆に割愛。
コンポーネントは何を与えられるべきか
React 自体は data => view を担当するのが主機能なので、view を出力するコンポーネントの構築に、この data に当たるもの以外が依存として入ってはいけないと感じた。具体的には state と props で、render() に必要な情報が全て賄われるべきだと思った。
| 種類 | 何が入るべきか |
|---|---|
| state | そのコンポーネントが管理する状態 |
| props | 親コンポーネントから渡される情報 |
仮想DOMと再描画
React を使うとき、そこには3つのDOMツリーがあると考えた方が良い。
- 実DOM。ブラウザがレンダリングに使うもの。
- 仮想DOM(A)。実DOMと同じであるものとして React 内部で保持されているもの
- 仮想DOM(B)。
stateが更新されたときに生成されるもの。
React が state の変更を受けて実DOMを更新するとき、以下のステップを踏む
- 新たな
stateを受けて、仮想DOM(B)が丸ごと生成される - 仮想DOM(A) と 仮想DOM(B) が比較され、仮想DOM(A)にどのような操作をすれば、仮想DOM(B)相当になるかの差分をコマンド化する
- 実DOMに差分コマンドを適用し、実DOMが新たな
stateを反映したものになる - 仮想DOM(A) が 仮想DOM(B) で上書きされる
実際に実DOMに対して実行されるコマンドは
el.textContent = "piyo"; el.style.color = '#ff0011';
といった感じでおなじみの本当にネイティブな命令だが、React の価値は、
- 変更を最低限にするための差分検知の仕組みがあることによって、実DOMの必要以上の更新が起こることがなく高速。
- その差分が、常に
stateやpropsに依存するために、普通に使っていれば状態と表示がズレることもない。
ということだ。
なぜjQueryが俺の魂を震えさせていたのか分からなくなった
上記からjQueryのそもそもの筋の良くなさに対して、さらに理解が深まった。
出来上がった実DOMに対してセレクタで走査して、アクセサで表示やイベントを手動で付け替えるというjQueryで当たり前に行われていたことを、サーバーサイドプログラミングで言うとこんな感じになる。
- jspやテンプレートエンジンを用いてHTMLを生成する
- DOMパーサーにHTMLを突っ込む
- cssセレクタでエレメントを取得する
- プロパティや内部のコンテントを書き換える
- 書き換えたDOMからHTMLを再生成してレスポンスにする
それが筋のいいことではないという事は一目見ても分かるし「最初からテンプレートの定義で表示を出し分けようよ」となるのは必至であるはずなのに、何となくjQuery使っている時は、それが不思議とは思わなかった。
なぜ仮想DOMという概念が俺の魂を震えさせるのか
しかし今翻って React のコンポーネントを見てみると、そこにはデータ定義とテンプレートがあり、それらがツリーになっているという、自分の目からはサーバーサイドでよく見た光景に映った。なぜ今までこうなっていなかったのだろうとさえ思った。何も新しい事ではなかったのである。
SPAや巨大で複雑なアプリケーションに使えることも利点なのかもしれないが、 かつて我々がサーバーからHTMLを出力していた時代と同じようなパラダイムがフロントエンドに来て、
- 階層化、モジュール化ができる奇麗で高速な設計
- それをもれなく view に反映できる奇麗で高速な仕組み
が我々の魂に響くのではないかと思った。
付録
奇麗な世界の汚い話
コンポーネントに shouldComponentUpdate というメソッドを生やす事で、state やprops の差分から
- 新たな
stateを受けて、仮想DOM(B)が丸ごと生成される - 仮想DOM(A) と 仮想DOM(B) が比較され、仮想DOM(A)にどのような操作をすれば、仮想DOM(B)相当になるかの差分をコマンド化する
のステップを実行すべきか、すべきでないかを通知する事ができる。これは、state やprops が更新されても差分コマンドがゼロ(変更無し)になるパターンで探索をスキップできるのでパフォーマンスが上がる。しかしコードの可読性や保守性が下がったり、メンテナンス時に思わぬ罠になったりするというのは明らかだろう。。。
奇麗な世界の汚い話2
差分コマンドが最小限になるとは言っても document.createElement とか el.appendChild などのツリー構造の変更というのは相対的にコストが高く、表示/非表示を切り替えるのにエレメントの付け替えを行うより、差分が el.style.display = "block" or "none" で解決される形にしたほうが実DOM更新が高速化するなどの泥の紹介があった。こうなってくるとコードやテンプレートに意味がつき始めて闇が生成される。。。
無線LAN環境を更新した
無線遅い問題
無線 LAN のスループットが安定せず、動画など巨大なデータのダウンロードでも定期的に引っかかりが起こることに気づいた。チェックツールで確認すると周囲には無線 LAN の電波が無秩序に飛び交っていた。自宅は都心に極めて近い住宅密集地。周囲の家からあまりよく設定されていないアクセスポイントの電波が睨み合うように電波のチャンネルを切り替え合い、その度に無線電波の干渉具合が変わり、パケットロス、ひいては TCP のウインドウサイズのリセットなどが起こったのだろう。
現状
これが現状のネットワーク構成である。
2010年に BUFFALO Air Station WHR-G301N
設備買い替え
そこで、次のような効果を狙って無線 LAN アクセスポイントの買い替えを行った。
- 無線のギガビット化。801.11ac を使えるようにしてボトルネックにならないようにする
- アンテナの強化により、周囲の無線電波に負けないような電波強度を得る
購入したのは以下の無線 LAN ルーターである。 ルーターではあるものの、アクセスポイント(無線ハブ)として使うのが目的だ。
更新後の構成である。
当然アクセスポイント自体への接続も GbE となる。 図の赤い部分が主に変更される部分だが、電波環境の改善により他の無線端末にも恩恵はあるだろう。
結果
電波強度は非常に高い。法律の範囲内ではあるものの過剰なレベルなので、多少は出力を抑えても良いかもしれない。
| 端末 | G301N | Archer C7 |
|---|---|---|
| Androidスマホ(11n) | 40-50Mbps | 100-130Mbps |
| Kindle(11n) | 40-50Mbps | 100-120Mbps |
| ThinkPad(11n->11ac) | 50Mbps | 240-300Mbps |
ざっくり計測でこんな感じになった。 11n / 11ac ともに理論値の3割程度出ているので、実効速度としては申し分ない。
ハマりポイントとこれからの課題
WAN側ポートが使えない問題
Archer C7 を無線 LAN ルーターとして使う分には、WAN 側を上位ネットワークに接続し、LAN 側のポートと無線を下位のネットワークとして分離するのが常識的な構成のため、普通に設定可能だ。しかし、アクセスポイント(ハブ)として使おうとしたときに、設定画面からでは WAN 側 と LAN 側のそれぞれのポートを、同じネットワークセグメントにあるものとして扱うことができない(エラーとなる) そこで、LAN 側を既存のネットワークに繋ぎ、WAN 側が存在しない状態で、既存のネットワークを無線へと拡張する必要がある。そしてその方法は添付の書類や公式サイトには全く書かれていない。方法について、以下のエントリが大変参考になった。
開幕「添付書類を完全無視しろ」と書いてあって大変味わい深い。
電波どうするか問題
Archer C7 は 3x3 MIMO 対応なので、例えばチャンネルを固定してバンド幅増やしてみたいなことをするともうちょっと改善できる(今は自動設定)と思うが、まだその部分を煮詰められていない。
ファームウェアどうするか問題
openwrt / dd-wrt の両方存在する。
https://wiki.openwrt.org/toh/tp-link/tl-wdr7500
TP Link Archer C7 - DD-WRT Wiki
さすがに買った直後に博打するのはどうかと思うので、しばらく使って満足したらここら辺に挑戦してみたい。
