9/19 17:30 オンラインイベントの実況

9/19(土) 17:30、スペシャルトークとミニライブからなるオンラインイベントが無料配信されます。
このイベントもキュアスタ！の実況対象ですので、ふるってご参加ください。

『ヒーリングっど♥プリキュア』スペシャルトーク＆ミニライブ生配信
～おウチでうたって♪おどっちゃおう！～
http://www.toei-anim.co.jp/tv/precure/news/2020091101.php

管理人が考える「ランキング」

以前から何度か言っていますが、キュアスタ！では今後、「投票により順位を決定する企画」を実施する予定はありません。
この記事では、管理人がランキングについて思うところを語っていきます。

記事の長さの割には、内容がないと感じる方もいるかもしれません。また、以前した話ともそれほど差がありません。
途中で読むのに飽きた方は、以下の結論だけをお持ち帰りください。

  • キュアスタ！では、ランキング企画は今後決してやらない。
  • メンバー同士でのランキングの話題にまでは干渉しない。
  • ひとりの参加者としての管理人も、メンバー同士のランキングの話題に絡むことは多分ない。

全プリキュア大投票

ここから本題。
思い出したくなかった出来事について、今一度触れなければいけませんが、自分の考えをまとめる為には必要なことなので。

ひとつのツイートを紹介しましょう。
HK BSプレミアムで放送された番組「全プリキュア投票」について、番組が終わったあとにスタッフが総括として載せたツイートです。

「全プリキュア大投票」に投票いただいたみなさん、そして生放送をご覧いただいたみなさん、本当にありがとうございました。ランキングは出ましたが、大切なことは順位ではなく、一人一人の心のなかにあるベスト・プリキュアですよね。
https://twitter.com/nhk_animeworld/status/1172898993044541440

感情をあらわにすると、皆さんに「引かれてしまう」ことは重々承知の上で、このツイートについてだけは思った通りの感想を言わせてください。
はらわたが煮えるほど腹が立ちました。 公私合わせて、ここ数年でこれほど腹を立てた出来事がなかったほどです。

このツイートが「名言」であるかのように称賛していたファンもいたようですが、私には全く同意できませんでした。とは言っても、異論があると言っているのではなく、むしろ逆。
「誰になんと言われようと好き」という気持ちは、本来はファン活動の根底にあるべき姿勢です。ファン活動の中で自分の気持ちこそが大切であることは、あえて断られるまでもなく「三辺の長さが等しい三角形を正三角形と言う」レベルであたりまえのこと。
私が腹を立てたのは、ファン心理を踏みにじった番組スタッフに、これを言う資格がないという点です。

NHKが本気でこう思っていたなら、そもそも番組自体が存在しなかったはず。何故なら、ランキングという行為自体が「視聴者全員を楽しませるべき」という前提と矛盾するからです。ランク外作品（またはプリキュア）のファンへの配慮は、一切ありませんでした。
自分の一番好きな作品やプリキュアが、1秒たりとも紹介されずに傷ついたファンは多く居たでしょう。私もそうしたファンのひとりでしたが、各々のプリキュアがリアルタイムで放送されていた時に、現役の幼女先輩だった方たちもここには多く含まれます。
特定の推しキュアがいないプリキュアファンにも、「平成アニメのベスト100を選ぶ番組の中で、プリキュアシリーズのどれか1作でも、1秒たりとも紹介されなかった」時の気持ちならば想像できるでしょう。

プリキュアシリーズの生みの親、鷲尾天さんをご存知の方も多いでしょう。
「鷲尾さんは、この番組にもっと熱い想いをこめていたはず。誤解も甚だしい」と反論する方も居るかも知れません。鷲尾さんは、事前に以下の様なメッセージを残されています。

私は以前から「各世代の作品・キャラクターに順位や上下はない」と言い切ってきましたので、戸惑っておられる方もいらっしゃるかと思います。
今回、誤解を恐れず踏み切ったのは、昨年の「プリキュア15周年」がきっかけです。
昨年は大変多くのファンの皆様と接する機会を持たせていただきました。お子様方はじめ、かつて応援してくださって今やすっかり大人になった皆様の姿と、語り尽くせない想いに接して大変感激いたしました。
この「語り尽くせぬ想い」をなんとか形にすることは出来ないだろうか、というのが昨年積み残した課題でもありました。
http://www.toei-anim.co.jp/tv/precure/news/2019071201.php

さすがにいいことも仰っているのですが、ご自身の矛盾も認めています。
「語り尽くせぬ想いを形にする」為に、誰かを傷つけずに行うことができないランキングという手段を選んだ理由について、全く説明がなく納得できません。

最後にもうひとつ、プリキュアファンのツイートを紹介して締めくくります。

全プリキュア大投票でキュアプリンセスがランクインしなくて悲しい😢😢僕の過去に描いたキュアプリンセスで魅力伝われ😢
https://twitter.com/bittan1201/status/1173036258915999746

管理人の考える「ランキング」

そもそも、プリキュアファンを楽しませるはずだった番組に傷つけられる。こんな理不尽があってよいのでしょうか？
キュアスタ！はこの様な、プリキュアファンという「同士」を傷つけることを避けられないイベントを、決してやることはないと宣言します。 「一人一人の心のなかにベスト・プリキュアがいる」ことを忘れてはならず、これは私が運営を続けてゆくにあたって、決して譲ることが出来ない条件です。

鷲尾さんのコメントから言葉をお借りすれば、「語り尽くせぬ想い」をあえて語り尽くすようなイベントになら挑戦してみたいですね。

2020.9.9
キュアスタ！管理人 ぷーざ

クリッピング

管理人が個人的に利用する為に実装した機能ですが、もしご興味があれば、ご利用ください。

機能概要

  • 公開キュア！を、MarkdownファイルとしてDropboxに保存（クリップ）します。
  • 外部のGROWIサーバへのクリップも可能ですが、ここでは説明しません。

設定の手順

Dropboxにアカウント登録

  • Dropboxのアカウントをお持ちでなければ、登録してください。

アプリケーションを登録し、アクセストークンを取得

  • Dropboxで、アプリケーションの登録を行ってください。
  • 登録後、そのアプリケーションの画面で Generated access token ボタンを押下。
  • 表示されたトークンを、お手元のメモアプリ等に控えてください。

環境設定画面

  • HOMEを開く。
  • その端末で初めてHOMEを利用する場合は、トークンの登録（アプリケーションの認証）を最初に行うこと。
  • 登録済みの場合は、環境設定画面へ。
  • Dropboxの設定を開き、先ほどのアクセストークンを貼り付け、「更新」ボタン。
  • 「現在の設定」にDropboxのトークンが加わったことを確認し、設定終了。

利用の手順

  • 利用は簡単です。「ブックマーク」操作を行ってください。（以下）
  • Mastodon本来のブックマークに加え、DropboxにもMarkdownファイルが保存されるようになります。
  • 例えばiOSやmacOSには、Dropboxに対応したMarkdownエディタUlyssesがあり、Markdownファイルの管理を行うことができます。

利用上の注意

  • クリップできるのは、「公開」のキュア！だけです。「未収載」以下の場合は、Mastodon本来のブックマークだけが保存されます。 Dropboxは個人用途であり、クリッピングが即公開につながるわけでもないので、未収載以下のキュア！もMarkdownで保存できるようにしました。
  • ブックマークはMastodonでは、 3.1系で追加された比較的新しい機能です。Tootle等、多くのユーザーが利用しているアプリでも未実装な場合があります。
  • 対応アプリか、WebUIから利用してください。

技術的な詳細

https://github.com/pooza/mulukhiya-toot-proxy/wiki/DropboxBookmarkHandler

Monitを導入

Monitとは

タイトルの通りですが、キュアスタ！にMonitというツールを導入しました。
サーバ上でMastodonプロセスがダウンした場合に、それを自動で検知し、再起動したりできるツールです。

「はて？それはそもそも、systemdの標準機能なのでは？」と思った人もいたかも。
ご指摘自体は間違いではないのですが、キュアスタ！のサーバはわたしの思い入れからFreeBSDで動作しており、systemdの機能を利用することができません。

systemdの代替というわけでもないですが、最近まではgodという、少し古いが枯れたツールを使っていました。
このgod、しばらくメンテナンスされておらず、使いづらいところも出てきていて、そろそろ後継の環境をと思っていたところだったのです。

rcNGとは

ところでFreeBSDでのデーモン起動は、一般的にはrcNGというNetBSD由来の機能により行われます。
rcNG準拠の起動スクリプトを書けば、サーバ機自体が起動した時のデーモン各々の起動を自動化できるだけでなく、例えば拙作モロヘイヤであれば service mulukhiya start 等のコマンドで手動起動を行うこともできる様になります。

話が逸れましたが、Mastodon等をMonit対応にする為には、それぞれをrcNG対応にするのが近道と感じました。（理由はのちほど）
例えばMastodonは、ざっくり以下の3つのプロセスで構成されますが、（各々の正しい呼び方があるわけではない様ですが、一般にもこれらの名前で呼ばれることが多い様です）

  • Mastodon Web
  • Sidekiq
  • ストリーミングAPI

それぞれについて起動スクリプトを書く必要があります。
今まではgodによる起動を行っていた為、rcNGの一般的な起動スクリプトは必ずしも必要ではありませんでした。

rcNG対応起動スクリプト

今回書いたのが、以下の様なもの。慣例に従って書いた、あまり技巧的な記述もないないベタなものですw /usr/local/www/mastodon にMastodonがインストールされ、Mastodonの実行ユーザーmastodonが既に作成されているとして。
また、それをふまえて/etc/rc.confに以下のような記述が必要です。（最近はsysrcというコマンドもある為、自動化は容易）

1
2
3
mastodon_enable="YES"
mastodon_path="/usr/local/www/mastodon"
mastodon_user="mastodon"

/usr/local/etc/rc.d/mastodon-web

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#!/bin/sh

# PROVIDE: mastodon_web
# REQUIRE: LOGIN

# Add the following line to /etc/rc.conf to enable `mastodon_web':
#
#mastodon_enable="YES"

. /etc/rc.subr

name="mastodon_web"
rcvar="mastodon_enable"

load_rc_config "mastodon"
: ${mastodon_enable="NO"}
: ${mastodon_path=""}
: ${mastodon_user=""}

export PATH=${PATH}:/usr/local/bin:/usr/local/sbin
export LANG=ja_JP.UTF-8
export LC_ALL=ja_JP.UTF-8

start_cmd=${name}_start
stop_cmd=${name}_stop

mastodon_web_start() {
  cd $mastodon_path
  sudo -u $mastodon_user zsh -c 'RAILS_ENV=production bundle exec rails server puma | logger -t mastodon_web &'
}

mastodon_web_stop() {
  pkill -U $mastodon_user -f puma
}

run_rc_command "$1"
  • zshから起動しているのは、rbenv環境が.zshenvで初期化されている為。起動スクリプトにzshを使うのは、あまり一般的ではないかもしれません。
  • 本当は、環境変数RAILS_ENVの大元は/etc/rc.confに書きたいところですね。実現にはちょっと工夫が必要なので一旦は保留でベタ書き。
  • 私自身は、この起動スクリプトをChefで設置しています。環境変数RAILS_ENVは実際には、ほんとにベタ書きしているわけではないです。

/usr/local/etc/rc.d/mastodon-sidekiq

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#!/bin/sh

# PROVIDE: mastodon_sidekiq
# REQUIRE: LOGIN

# Add the following line to /etc/rc.conf to enable `mastodon_sidekiq':
#
#mastodon_enable="YES"

. /etc/rc.subr

name="mastodon_sidekiq"
rcvar="mastodon_enable"

load_rc_config "mastodon"
: ${mastodon_enable="NO"}
: ${mastodon_path=""}
: ${mastodon_user=""}

export PATH=${PATH}:/usr/local/bin:/usr/local/sbin
export LANG=ja_JP.UTF-8
export LC_ALL=ja_JP.UTF-8

start_cmd=${name}_start
stop_cmd=${name}_stop

mastodon_sidekiq_start() {
  cd $mastodon_path
  sudo -u $mastodon_user zsh -c 'RAILS_ENV=production bundle exec sidekiq -C config/sidekiq.yml | logger -t mastodon_sidekiq &'
}

mastodon_sidekiq_stop() {
  pkill -U $mastodon_user -f sidekiq
}

run_rc_command "$1"
  • Mastodon Webの起動スクリプトとそれほど違いがあるわけではありません。説明割愛。

/usr/local/etc/mastodon-streaming

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#!/bin/sh

# PROVIDE: mastodon_streaming
# REQUIRE: LOGIN

# Add the following line to /etc/rc.conf to enable `mastodon_streaming':
#
#mastodon_enable="YES"

. /etc/rc.subr

name="mastodon_streaming"
rcvar="mastodon_enable"

load_rc_config "mastodon"
: ${mastodon_enable="NO"}
: ${mastodon_path=""}
: ${mastodon_user=""}

export PATH=${PATH}:/usr/local/bin:/usr/local/sbin
export LANG=ja_JP.UTF-8
export LC_ALL=ja_JP.UTF-8

start_cmd=${name}_start
stop_cmd=${name}_stop

mastodon_streaming_start() {
  cd $mastodon_path
  sudo -u $mastodon_user sh -c 'NODE_ENV=production BIND=0.0.0.0 npm start | logger -t mastodon_streaming &'
}

mastodon_streaming_stop() {
  pkill -U $mastodon_user -f streaming
}

run_rc_command "$1"
  • こちらもあまり違いはありませんが、環境変数BINDも設定しています。これはMastodonとnginxが別のホストで動いている場合に必要な記述で、大抵の環境では必要ありません。
  • これまで同様loggerコマンドにより、標準出力をsyslogに送っています。MastodonのストリーミングAPIは、npmlogモジュールでログの出力を行っていますが、デフォルトの出力先は標準エラー出力である為、標準出力にログを出力する（最終的にログをsyslogに送る）為には、ストリーミングAPIへの改造が必要となります。（手前味噌ですが、拙作パッチ）

Monit自体の導入

パッケージのインストール

実はここまで、試行錯誤にけっこう時間を使ってしまいましたが、あとは流れ作業でさくさくと。以下実行。

1
2
sudo pkg install monit
sudo sysrc monit_enable=YES

/etc/rc.confにmonit_enable="YES"の記述があることを確認。

/usr/local/etc/monitrc

/usr/local/etc/monitrcに以下記述。
/usr/local/etc/monitrc.sampleのコピーから修正するのでも可。

1
2
3
4
5
6
set daemon 30
set log syslog
set httpd port 2812 and
  allow 127.0.0.1
  allow 203.xxx.xxx.xxx # 管理人自宅の固定IPアドレス
include /usr/local/etc/monit.d/*
  • パーミッションは600じゃないとエラーがでる様です。
  • 一般的にはメールを送る機能も併せて設定するようですが、Sensuによる監視系が別途構築されていることもあり、不要なのでわたしは省いています。
  • ここで重要な設定は、 監視を30秒周期で行う というところ。

プロセス個別の設定

キュアスタ！ではMastodonだけでなく、モロヘイヤや真琴さん含め、多くのプロセスが動いています。
ここではMastodonを例にして。

/usr/local/etc/monit.d/mastodon

1
2
3
4
5
6
7
8
9
10
11
check process mastodon-puma with matching "puma .* \[mastodon\]"
  start program = "/usr/sbin/service mastodon-web restart" with timeout 60 seconds
  stop program = "/usr/sbin/service mastodon-web stop"

check process mastodon-sidekiq with matching "sidekiq .* mastodon"
  start program = "/usr/sbin/service mastodon-sidekiq restart" with timeout 60 seconds
  stop program = "/usr/sbin/service mastodon-sidekiq stop"

check process mastodon-streaming with matching "mastodon/streaming/index.js"
  start program = "/usr/sbin/service mastodon-streaming restart"
  stop program = "/usr/sbin/service mastodon-streaming stop"
  • プロセス名の正規表現マッチングを行い、先ほど設定した30秒ごとに生死を確認します。
  • start programとstop programに、実際に実行するコマンドを記述。ここにあまり複雑なコマンド列は指定できない為、こまかな動作はコマンド（スクリプト）側に記述する必要があります。rcNG準拠の起動スクリプトを用意しなければいけなかった理由はこれ。
  • 通常はここに、プロセス起動の失敗回数などに関連した記述も行われるようですが、おいおい詰めていきたいです。

Monitの起動

以下実行。

1
sudo service monit start

実行後に2812ポートをWebブラウザで叩くと、以下の様な管理画面が。

ここまで到達すれば、キラやば☆と言うほかはありません。

バックアップ

以下のバックアップ処理を自動化しています。

Mastodon

  • 設置先ディレクトリをバックアップサーバへrsync（1日ごと）

PostgreSQL

  • zfstoolsによる、データベースディレクトリのスナップショット作成（1時間ごと）
  • ダンプを作成、バックアップサーバへrsync（1日ごと）

Redis

  • バックアップサーバへrsync（1日ごと）

メディアストレージ

Slack互換webhook

ボットや自動投稿を作る方の便宜の為、webhookを提供しています。
仕様上は、Slackの同名機能のサブセットです。簡単なSlackボットなら、既存のものを無改造でキュアスタ！対応にできるかもしれません。

利用の手順

「東映アニメーション プリキュア公式」の新着情報ボットのAtomフィードを、IFTTTを使ってwebhookに転送する例で説明します。

RSS/Atomフィードを調べる。

このボットは、以下のAtomフィードをもとにキュア！を行っています。
https://precure.b-shock.org/feed/v1.0/site/toei

webhookのURLを調べる。

モロヘイヤHOMEで、webhookのURLを調べられます。
その端末でトークンの登録（アプリケーションの認証）をまだ行っていなかったら、最初に実行してください。
スマホアプリの設定でおなじみの画面が出てきますので、指示に従ってください。

トークンが登録済みなら、「環境設定」画面にwebhookのURLがあるはずです。

画面にも赤字で書かれていますが、このURLは決して他人に教えてはいけません。たとえ相手が管理人であっても。

ここまでで事前準備は終了。このあと実際に、IFTTTで登録を行っていきます。

トリガー

IFTTTの画面上で、Createを実行します。
rss 等の検索語で RSS Feed トリガーを検索し、これを選択。

そして、先ほどのフィードURLを設定。
AtomフィードもRSSの一種とみなされ、登録可能です。今さら野暮を言う様ですが。

アクション

webhook 等の検索語で Webhooks アクションを検索し、これを選択。

設定内容は、こんな感じ。

URLは、先ほど調べたwebhookのURL。
Bodyには、たとえば以下の様なJSONを。

1
{"text":"<<<{{EntryTitle}}>>>\n<<<{{EntryUrl}}>>>"}

保存して実行しましょう。以上です。

公開範囲アイコン

Mastodon 3.2.0の適用に伴い、重複する公開範囲アイコン（「未収載」や「フォロワー限定」で表示される鍵マーク）を削除しました。