ただのにっき

■ GREE版ミリオンライブが終了

かねてから予告のあったとおり、GREE版のミリオンライブ(グリマス)が今日の正午をもってサービス終了した。サービス初日から終了まで、1日も欠かさずプレイしたゲームが終わるのは、これが初めてだなぁ。

最後の記念に、お気に入りの3人に、これまたお気に入りの3rdライブ衣装を着てユニットを組んでもらったよ:

偶然とはひどいもので、ミリオンでの主担当である志保は、THEATER Activitiyでのり子と、THEATER Boostで美也と一騎討ちの末に敗れるというね。なかなか心苦しい思い出ではあります。

Xboxの無印版のころからアイマスを見てきた身としては、これもまた「アイマス独特のリセット」の一例であって、ひとつの展開が終息したところでメタレベルでは連続しているという実感があるから、じつのところそんなに悲しくはない。まぁ寂しい気持ちはあるし、続けられるもんなら続けて欲しかったとは思うのは否定しないが*1、グリマスは実装のせいかモバイルで遊ぶには重すぎたからなぁ。ゲームとしてはストレスフルだったよね。

Project iM@Sはあいかわらず用意周到で、前日のニコ生でミリシタの新展開を発表していて、これが(おそらく)グリマスの血を引くイベントではないかと思われるとんでもない新曲なものだから、今日のショックをずいぶんと和らげてくれているんだよね*2。おれたちのミリオンはこれからも変わらず狂気(と感動)を振りまいてくれるんだろう。そう信じていいんじゃないかな。

■ GASとSlackで繰り返し作業用のリマインダを作っている

こないだ作ったSlackボットに味をしめて、以前から欲しかったリマインダを作っている。とりあえず動くようになったレベルだけど、便利すぎて鼻血が出るわ*1。サーバレスアーキテクチャ万歳！

Slackがデフォルトで提供してるリマインダは、メッセージに選択肢が追加されてて「何時間延長するか」が選べるようになっている。これすごく便利なんだけど、選択肢がお仕着せで、目的の延長時間がない場合はまったく役に立たない(と思う。おれの知らない機能があるかも知れないが)。これを、内容に合わせて選択肢も指定できると再設定の手間がなくなっていいと思うんだよね。

たとえば(はい、ここからたとえがちょっとアレになりますよ)、モバマスのぷちレッスンは寝てる間に10時間、起きてる間に10時間と3時間のコースを組み合わせるといい感じになるんだけど、この「10時間」や「3時間」が延長の選択肢にあるといいわけよ。

で、こんな感じのを作ってる。指定した時間になったらSlackにこういうInteractive Messageを投げてくれて:

「10hours」を押したら10時間後にまた同じリマインダをくれる:

スプレッドシートに行を足すだけで、別のリマインダを増やせる。もちろん選択肢も個別に設定できる*2。そうそう、ソシャゲだけじゃなくて、ポモドーロタイマーなんかにも使えるかもね(←取ってつけた感)。

コードは(Chrome拡張経由で)GitHubに置いてあるけど、まだドキュメントがないので使えないでしょう。というか、SlackAppのIncomingWebhook経由だとユーザ名やアイコンを指定しても無視されるんだけど、どうすればいいんだろう? postMessageメソッドを使うようにしないといかんのだろうか。このへんをなんとかしたい。見た目重要。(2018-03-20追記)ドキュメント書いた。あと、SlackAppの表示名やアイコンはアプリ自身(オーナー)が指定したものだけが使われるようだ。ユーザサイドでも表示名を変更できるようにはなっているけど、反映されないし、アイコンは設定すらできない。

■ (自分で書いた)誤ったHTTPヘッダのせいで苦労した話

わさますのコミュニケーション基盤であるmassr、いまはHerokuで動かしているんだけど、長年の運用でMongoDBの容量も増えてきてコスト的にも厳しい感じになってきたので、VPSでも借りて引っ越そうという算段をしている。とりあえずGCE(Google Compute Engine)の無料枠でためそうかという流れに。

Dockerを使ってmassr本体とMongoDB、Memcachedはそれぞれ別のコンテナに入れ、reverse proxyとしてフロントに立てたnginxにhttpsをさばいてもらうという、(たぶん)昨今ではオーソドックスな構成。

で、普通に会話するくらいのところまでは問題なく動いたんだけど、フォームを経由しないLikeなんかの動作が403を返して失敗する。使い慣れないDocker上でいろいろ調べると、Rack::Csrfが403を返している。CSRFトークンが渡ってきてない。

ブラウザ上のjQuery*1はちゃんとHTTPヘッダにトークンを乗せている。でもmassrには渡ってきてない。てことは途中のnginxが怪しい?

調査過程はすっ飛ばして、結論から言えば犯人はこれである:

-   xhr.setRequestHeader('X_CSRF_TOKEN', token);
+   xhr.setRequestHeader('X-CSRF-TOKEN', token);

こんなHTTPヘッダ、nginxが取り次いでくれるわけがない。おそらくはる～～～か昔、jQueryでAjaxをやるにあたって参考にした(いまはもう見つけられない古い)サイトからのコピペが原因だ。まぁ、HTTPヘッダなのに「_」区切りになってる時点で気づくべきだったのだ。自分が悪い。

これがなんで今まで動いていたかというと、まず(これは想像だけど)Herokuはこの手のおかしなHTTPヘッダもアプリまでちゃんと運んでくれている。で、さらに、Rack::Csrfにこんなコードがある:

def self.rackified_header
  "HTTP_#{@@header.gsub('-', '_').upcase}"
end

このミドルウェアでは内部的に「_」を区切りに使うので、HTTPヘッダの区切りを強制的に「-」から「_」に変えているんだな。で、結果として誤ったヘッダはそのまま(変換されることなく)内部表現として扱われると。

よかれと思って書かれたコードの連鎖で本来の問題が隠れてしまうの、つらいですね……。