無印吉澤

Site Reliability Engineering(SRE)、ソフトウェア開発、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

趣味で作っているサービスを Rails 5.0 から Rails 5.1 へアップグレードする

f:id:muziyoshiz:20170724152414p:plain

最近、趣味で作っているサービス(Admiral Stats)を Rails 5.0.0.1 から 5.1.2 にアップグレードしました。サービスが小さいので、それほど苦戦するポイントは無かったのですが、調べたこと、やったことをメモしておきます。

調べたこと

とりあえず、関連しそうな情報に一通り目を通しました。

アップグレード方針

上記のページを見る限り、今回は移行対象のアプリが小さいこともあり、特に問題もなくアップグレードできそうでした。

まず、「application.secretsですべてのキーをシンボルとして読み込むようになった」はコード中の参照箇所を確認して、問題なし。JWT のエンコード、デコード時に Rails.application.secrets.secret_key_base と参照していましたが、これは Rails 5.1 でも動作しました。

秘密情報の暗号化は、元々 MySQL のパスワードなどは Apache から環境変数(SetEnv)で渡していたので、この方針を踏襲することにして変更せず。config/environments/production.rb で config.read_encrypted_secrets = false と書いておいて、今まで通りに secrets.yml を使います。

Yarn のサポート、Webpack のサポート、デフォルトでのjQuery依存の廃止、については、引き続き jQuery を使うことにして今回は気にしないことに。

あと、主キーのデフォルト型が BIGINT に変更に変更される件については、テーブル作成時期によって主キーの型が変わるのは混乱しそうなので、INT に統一することにしました。アップグレード時に必要な作業は特にないですが、テーブル作成時に id: integer を付ければ OK(以下はその例)。ただ、これはうっかり忘れることが多そうなので、generate model 時に必ず自動で付くようにしたい……。

class CreateBlueprintStatuses < ActiveRecord::Migration[5.1]
  def change
    create_table :blueprint_statuses, id: :integer do |t|

やったこと

Rails 5.0 系の最新版へのアップグレード、および関連 gem のアップグレード

まずは Gemfileのバージョンを更新。

- gem 'rails', '~> 5.0.0', '>= 5.0.0.1'
+ gem 'rails', '~> 5.0.0', '>= 5.0.4'

そして bundle update を実行。参考にしたページには bundle update rails を実行して rails 関係だけをアップグレードし、関連 gem は後回しにすべき、というアドバイスがあったのですが、すっかり忘れてました……。今回はそのまま続行。

最後に、動作確認のためにテストがある部分は rails test で確認し、ない部分は手作業で軽くポチポチ確認。

Rails 関係では特に問題ありませんでしたが、rack-cors が 0.4.1 から 1.0.0 に上がった影響で動作が少し変わっていて rails test が失敗。その部分のテストコードを修正しました。

あとは、Capistrano が 3.6.1 から 3.8.2 に変わった影響で、動かない部分と、Deprecation Notice が出る部分があったのでそこを修正。

  • Capfile の修正
- lock '3.6.1'
+ lock '3.8.2'
  • Capfile で Git SCM plugin のロードを明示
# Include default deployment tasks
require "capistrano/deploy"

# Future versions of Capistrano will not load the Git SCM plugin by default.
+ require "capistrano/scm/git"
+ install_plugin Capistrano::SCM::Git

Rails 5.1.2 へのアップグレード

先ほどと同じく、まずは Gemfile のバージョンを更新。

- gem 'rails', '~> 5.0.0', '>= 5.0.4'
+ gem 'rails', '~> 5.1.0', '>= 5.1.2'

次は bundle update を実行。関連 gem はアップグレード済みなので、今回は rails 関連の gem のみがアップグレードされました。

そして rails app:update を実行。bin 以下と config 以下のファイルが、新規作成されたり上書きされたりします。git で差分を見て、既存の設定を上書きしている部分以外は、基本的に採用しました。

  • bin/setup
    • bin/yarn の読み込みがコメントアウトされた状態で追加された。参考のために残した
  # Install JavaScript dependencies if using Yarn
  # system('bin/yarn')
  • bin/yarn (新規作成)
    • 今回は使わないが、呼び出し自体は上記の通りコメントアウトされているので残した
#!/usr/bin/env ruby
VENDOR_PATH = File.expand_path('..', __dir__)
Dir.chdir(VENDOR_PATH) do
  begin
    exec "yarnpkg #{ARGV.join(" ")}"
  rescue Errno::ENOENT
    $stderr.puts "Yarn executable was not detected in the system."
    $stderr.puts "Download Yarn at https://yarnpkg.com/en/docs/install"
    exit 1
  end
end
  • config/application.rb
    • 以下の行が追加された。確認のうえで残した
+    config.load_defaults 5.1
  • config/cable.yml
    • Redis PubSub で使う prefix が追加された。設定しても、この自作サービス(Admiral Stats)では使わないが、自動生成されたまま残した
+  channel_prefix: admiral_stats_production
  • config/puma.rb
    • ビルトインサーバの設定。コメントが変わっただけ
  • config/routes.rb
    • 単純に空にされるだけなので、上書きされたものをもとに戻した
  • config/secrets.yml
    • 環境変数から読み込む運用にしているので、そのままにした
  • config/environments/development.rb
    • Cache-Control の表記が分かりやすい表記に変わった(max-age の長さは同じ)ため、そのまま残した
-      'Cache-Control' => 'public, max-age=172800'
+      'Cache-Control' => "public, max-age=#{2.days.seconds.to_i}"
  • config/environments/production.rb
    • config.read_encrypted_secrets = true という行が追加されるが、これを false に変更した
  • config/initializers/assets.rb
    • 以下の行が追加された。Yarn は使っていないが、そのままにした
Rails.application.config.assets.paths << Rails.root.join('node_modules')
  • config/initializers/cors.rb
    • 基本的な設定が作成されたが、このファイルは元々作成済みだったため、元に戻した
  • config/initializers/new_framework_defaults_5_1.rb
    • 以下の内容で作成された。そのままにした。
# Be sure to restart your server when you modify this file.
#
# This file contains migration options to ease your Rails 5.1 upgrade.
#
# Once upgraded flip defaults one by one to migrate to the new default.
#
# Read the Guide for Upgrading Ruby on Rails for more info on each option.

# Make `form_with` generate non-remote forms.
Rails.application.config.action_view.form_with_generates_remote_forms = false

# Unknown asset fallback will return the path passed in when the given
# asset is not present in the asset pipeline.
# Rails.application.config.assets.unknown_asset_fallback = false

最後に、動作確認のためにテストがある部分は rails test で確認し、ない部分は手作業で軽くポチポチ確認して、リリースしました。

まとめ

5.0 から 5.1 へのアップグレードは、それほど詰まるところはありませんでした。アップグレードが溜まってると辛くなるので、早いうちにやっておいてよかったです。

ただ、当たり前の話ですが、アップグレード前にはちゃんとテストを整備しておかないとダメですね。今回のアップグレード対象は趣味のサービスで、テストより機能追加を優先してしまっていたので、今回のアップグレードはおっかなびっくりでした。なにか僕の気付いていない問題が見つかったら、報告頂けたら緊急で対応します……。

艦これアーケード第2回イベント「南方海域強襲偵察!」 プレイデータ解析 〜甲種勲章の十分条件は何だったのか?

f:id:muziyoshiz:20170128164643p:plain

はじめに

2017年4月26日から5月31日まで、艦これアーケードの第2回イベント「南方海域強襲偵察!」が開催されていました。普通の人にこういう話をすると「アーケードゲームにイベントがあるの?」と言われるんですが、最近のアーケードゲームはネット接続してるので、期間限定イベントとか普通らしいです。

艦これアーケードの場合は、イベント期間だけ新キャラを入手できたり、凶悪なボスキャラと戦えたりします。一番難しい難易度は甲乙丙の「甲」で、これをクリアすると「甲種勲章」というアイテムを入手できました。

僕は艦これアーケードのプレイヤー(提督)向けに、プレイデータ管理ツール Admiral Stats というサービスを提供していて、ここに各プレイヤーのイベント攻略状況も集まっています。今回は、このデータをもとに、「甲種勲章」を入手できた提督に共通する特徴を探ってみました。

艦これアーケードと Admiral Stats については、以前スライドにまとめたので、興味のある方はこちらをどうぞ。

第2回イベント「南方海域強襲偵察!」について

今回のイベントは、前段作戦と後段作戦に分かれていて、それぞれの作戦に甲乙丙の難易度がありました。簡単な難易度をクリアすると、より難しい難易度に挑戦できるようになっていて、具体的には下図のような制限がありました。

f:id:muziyoshiz:20170629225150p:plain

(※1周クリア=1周目の掃討戦に出撃していること)

一番の目玉だった「大和」は後段作戦でしか入手できず、そのためには前段作戦に挑戦する必要がある……ということで、約1ヶ月間かなりの提督がゲーセンに詰めかけてました。

ちなみに、後段作戦の甲は出現までが面倒なうえに、とてもクリアさせる気があるとは思えない極悪難易度でした(※個人の感想です)(※褒め言葉です)。

集計対象のプレイデータ

今回は、前段作戦95名、後段作戦80名分のプレイデータが集まりました。

集計対象の詳しい情報は、以下の通りです。

  • 集計対象とした提督
    • 第2回イベントに参加して、Admiral Stats に1回以上プレイデータをアップロードした提督
  • 集計対象としたプレイデータ(イベント進捗情報、艦娘一覧など)
    • イベント攻略率と艦娘カード入手率は、2017年6月8日3:00時点のプレイデータを集計
    • レベルや経験値については、イベント終了時刻になるべく近いプレイデータを集計
      • 2017年6月8日3:00までにアップロードされたプレイデータのうち、イベント終了時刻(2017年5月31日23:59)に一番近い時刻にアップロードされたプレイデータ

SEGA の本家サイトから、イベント進捗情報をエクスポートできなくなったのは6月8日でした。Admiral Stats は毎日2時にデータをバックアップしているので、今回は6月8日 3:00のバックアップを使って解析しました。

プレイデータの解析結果

イベント攻略率

前段作戦

前段作戦の甲難易度をクリアしたのは全提督の 57.9 % でした。前段作戦は、まだ救いのある難易度だったので、この高い割合もわからなくはないです。

f:id:muziyoshiz:20170630003300p:plain

また、甲難易度をクリアした提督のうち 56.4 % が、レアカード(甲種勲章がプリントされた艦娘カード)を求めて、2周以上クリアしていました。10周以上クリアした提督は 10.9 % です。

f:id:muziyoshiz:20170630003334p:plain

詳細:イベント攻略率(南方海域強襲偵察! 前段作戦) - Admiral Stats

後段作戦

後段作戦の甲難易度をクリアしたのは全提督の 57.5 % でした。前段作戦よりもかなり難しくなっているのに、割合は全然変わってないのが不思議です。前段作戦しかアップロードしていない提督がいることによる影響を考えても、この割合はかなり高いような……。

f:id:muziyoshiz:20170630003356p:plain

また、甲難易度をクリアした提督のうち 60.9 % が、2周以上クリアしていました。10周以上クリアした提督は 17.4 % です。後段作戦は大和入手のチャンスがあったので、こちらのほうが前段作戦よりも周回されていたようです。

f:id:muziyoshiz:20170630003434p:plain

詳細:イベント攻略率(南方海域強襲偵察! 後段作戦) - Admiral Stats

艦娘カード入手率

以下は、このイベントでの新艦娘を入手できた提督の割合です。ちなみに、自分でドロップしたカードだけでなく、買ったり借りたりして読み込んだカードも「入手」に含みます。これは、公式プレイヤーズサイトの仕様による制限です。

目玉だけあって、大和の入手率が他より 10 % 以上低かったのがわかります。また、前段・後段の両方で入手できた阿賀野と能代は、5 〜 7 % 高くなっています。

図鑑 No. 艦種 艦名 N Nホロ N中破
131 戦艦 大和 43.3 % 6.7 % 2.2 %
137 軽巡洋艦 阿賀野 65.6 % 8.9 % 4.4 %
138 軽巡洋艦 能代 62.2 % 8.9 % 3.3 %
139 軽巡洋艦 矢矧 57.8 % 6.7 % 5.6 %
140 軽巡洋艦 酒匂 58.9 % 4.4 % 2.2 %

また、Admiral Stats の方ではまだ表示できていないのですが、その他の限定カードの入手率は以下のようになりました。実際にプレイした感覚からすると、意外と高いな、という印象です。

図鑑 No. 艦種 艦名 限定カード
102 航空戦艦 伊勢改 32.2 %
103 航空戦艦 日向改 40.0 %

詳細:艦これアーケードの艦娘カード入手率(南方海域強襲偵察!) - Admiral Stats

艦隊司令部レベル、および経験値

ここから先は、Admiral Stats 上で表示していない(自動集計機能がまだない)集計結果の紹介です。

Admiral Stats で上記のイベント攻略率を公開した際に、「こんなツールを欲しがるのはやりこんでるプレイヤーだけなんだから、実際のプレイヤー全体よりも攻略率が大幅に高いのでは?(意訳)」という指摘がありました。

その点を検証するために、まずは、ステージのクリア回数とステージの難易度によって増える「艦隊司令部レベル」の分布を出しました。この結果によると、レベル90以上の提督は 49.47 % です。

艦隊司令部レベル 提督数 割合
0 以上 10 未満 3 3.16 %
10 以上 20 未満 1 1.05 %
20 以上 30 未満 2 2.11 %
30 以上 40 未満 5 5.26 %
40 以上 50 未満 5 5.26 %
50 以上 60 未満 10 10.53 %
60 以上 70 未満 7 7.37 %
70 以上 80 未満 7 7.37 %
80 以上 90 未満 8 8.42 %
90 以上 100 未満 28 29.47 %
100 以上 110 未満 18 18.95 %
110 1 1.05 %
総計 95 100.00 %

また、艦隊司令部レベルを経験値に換算したものが以下の表です。レベル99になるのに経験値が 1,000,000 必要なので、イベント参加提督の 33.69 % がレベル99以上ということになります。

経験値 提督数 割合
0 以上 100000 未満 14 14.74 %
100000 以上 200000 未満 14 14.74 %
200000 以上 300000 未満 8 8.42 %
300000 以上 400000 未満 6 6.32 %
400000 以上 500000 未満 6 6.32 %
500000 以上 600000 未満 3 3.16 %
600000 以上 700000 未満 6 6.32 %
700000 以上 800000 未満 3 3.16 %
800000 以上 900000 未満 3 3.16 %
900000 以上 1000000 未満 0 0.00 %
1000000 以上 2000000 未満 23 24.21 %
2000000 以上 3000000 未満 5 5.26 %
3000000 以上 4000000 未満 2 2.11 %
4000000 以上 5000000 未満 0 0.00 %
5000000 以上 6000000 未満 2 2.11 %
総計 95 100.00 %

Admiral Stats のユーザにはやりこみ勢が多い、という主張は、まあ正しそうですね……。とはいえ、そうでないユーザも居るので、甲難易度をクリアした提督と、そうでない提督の差を調べることはできそうです。

ちなみに、艦これアーケードのレベルアップに必要な経験値は、艦これ本家と同じと言われています。Admiral Stats では 艦これ攻略 Wiki の「経験値」ページ を参考に経験値を計算しています。

攻略度と艦隊司令部レベル/経験値の比較

では、艦隊司令部レベルがどれくらい高ければ後段作戦の甲をクリアできたのか? それを調べるために、攻略度と、艦隊司令部レベル/経験値を比較したのが以下の表です。

この結果によると、後段作戦の甲をクリアできた提督は、最低でもレベル63、平均レベル96.3でした。艦これの経験値テーブルはレベル90前後から急上昇するので、経験値の平均を取ると1121310.2で、これはレベル100相当です。平均が高すぎる……。

甲クリア提督を見てもやりこみ度が高すぎるので、乙クリア提督を見たほうが参考になるかもしれません。後段作戦の乙をクリアできた提督は、最低でもレベル41、平均レベル79.2。経験値の平均は427060.0で、レベル83相当でした。この間のどこかに境界がありそうですね。

前段作戦の攻略度と、艦隊司令部レベル

攻略度 提督数 最大 最小 平均 標準偏差
甲攻略済 55 110 63 95.4 9.9
乙攻略済 15 97 30 66.8 19.4
丙攻略済 15 78 26 49.5 15.0
未攻略 10 65 6 32.5 21.6
総計 95 110 6 77.0 27.2

前段作戦の攻略度と、艦隊司令部経験値

攻略度 提督数 最大 最小 平均 標準偏差 平均(レベル換算)
甲攻略済 55 5900000 203400 1264850.9 1070768.8 99
乙攻略済 15 761500 43500 296233.3 200063.1 73
丙攻略済 15 356200 32500 138513.3 89758.1 53
未攻略 10 219500 1500 75690.0 73349.5 39
総計 95 5900000 1500 808893.7 980487.1 97

後段作戦の攻略度と、艦隊司令部レベル

攻略度 提督数 最大 最小 平均 標準偏差
甲攻略済 46 110 63 96.3 9.9
乙攻略済 15 97 41 79.2 16.0
丙攻略済 14 75 26 49.5 15.5
未攻略 5 52 6 29.4 19.1
総計 80 110 6 80.7 25.4

後段作戦の攻略度と、艦隊司令部経験値

攻略度 提督数 最大 最小 平均 標準偏差 平均(レベル換算)
甲攻略済 46 5900000 203400 1360919.6 1121310.2 100
乙攻略済 15 761500 82000 427060.0 191149.6 83
丙攻略済 14 319000 32500 138964.3 88616.0 53
未攻略 5 132700 1500 60000.0 52672.3 35
総計 80 5900000 1500 890671.3 1020211.4 98

攻略度と艦娘の練度の比較

艦隊司令部レベルが低くても、特定の艦娘だけレベルを上げていればクリアは可能だったはずです。そこで、攻略度と、一定レベル以上の艦娘の数も比較してみました。

艦隊司令部レベルよりも、こちらのほうが、甲提督と乙提督の差が激しいですね。イベント開始時の全艦娘110隻をレベル99にしているようなやりこみ勢(凄すぎる……)が平均を上げています。

レベル70以上の艦娘数0で甲攻略済みの提督もいたので、低レベルでも攻略は可能だったみたいです。ただ、「高レベル艦娘を揃えていて、乙攻略済み以下」という提督はほとんどいないので、「レベルを上げれば物理で殴れた」とも言えそうです。

前段作戦

Lv50以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 114 6 32.4 24.8
乙攻略済 25 0 9.0 6.9
丙攻略済 8 0 2.9 2.9
未攻略 2 0 0.6 0.8
総計 114 0 20.7 23.6

Lv70以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 114 0 19.1 20.8
乙攻略済 8 0 2.3 2.5
丙攻略済 3 0 0.3 0.8
未攻略 0 0 0.0 0.0
総計 114 0 11.4 18.2

Lv90以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 110 0 10.6 18.7
乙攻略済 1 0 0.2 0.4
丙攻略済 0 0 0.0 0.0
未攻略 0 0 0.0 0.0
総計 110 0 6.1 15.2

Lv99の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 110 0 5.6 16.0
乙攻略済 0 0 0.0 0.0
丙攻略済 0 0 0.0 0.0
未攻略 0 0 0.0 0.0
総計 110 0 3.2 12.5

後段作戦

Lv50以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 114 6 34.8 25.6
乙攻略済 25 0 11.8 5.9
丙攻略済 8 0 3.4 2.7
未攻略 2 0 0.6 0.8
総計 114 0 22.9 24.2

Lv70以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 114 1 21.0 21.8
乙攻略済 8 0 3.7 2.3
丙攻略済 1 0 0.1 0.3
未攻略 0 0 0.0 0.0
総計 114 0 12.8 19.1

Lv90以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 110 0 12.0 20.1
乙攻略済 2 0 0.5 0.6
丙攻略済 0 0 0.0 0.0
未攻略 0 0 0.0 0.0
総計 110 0 7.0 16.3

Lv99の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 110 0 6.5 17.4
乙攻略済 1 0 0.1 0.2
丙攻略済 0 0 0.0 0.0
未攻略 0 0 0.0 0.0
総計 110 0 3.8 13.6

攻略度と雷巡改二(大井改二・北上改二)の所有数の比較

今回、特に後段作戦E-6は、雷巡の改二を持っているかいないかで難易度が大きく変わる、と言われていました(参考:南方海域強襲偵察! E-6 - 艦らぼ)。

そこで攻略度と、雷巡改二の所有数も比較してみました。以下の表の読み方ですが、2は大井改二と北上改二を両方持っている、1は片方のみ持っている、0はどちらも持っていない、という意味です。

こうしてみると、雷巡改二が1隻の場合と2隻の場合では、甲難易度の攻略率が大きく違うのがわかります。

前段作戦

攻略度 0 1 2 総計
甲攻略済 11.58% 8.42% 37.89% 57.89%
乙攻略済 6.32% 4.21% 5.26% 15.79%
丙攻略済 12.63% 2.11% 1.05% 15.79%
未攻略 10.53% 0.00% 0.00% 10.53%
総計 41.05% 14.74% 44.21% 100.00%

後段作戦

攻略度 0 1 2 総計
甲攻略済 10.00% 7.50% 40.00% 57.50%
乙攻略済 5.00% 5.00% 8.75% 18.75%
丙攻略済 13.75% 2.50% 1.25% 17.50%
未攻略 6.25% 0.00% 0.00% 6.25%
総計 35.00% 15.00% 50.00% 100.00%

雷巡改二(大井改二・北上改二)の所有数と、艦隊司令部経験値の比較

しかし、レアカードを持っているのはやりこんでいるからで、攻略度に直接影響しているのはやりこみ度の方なのでは?とも考えられます。

そこで、雷巡改二の所有数と艦隊司令部経験値と比較した結果は以下の通りです。やりこみ勢は雷巡改二を両方とも持っていることが多いが、片方だけ持っている提督とどちらも持っていない提督の差はそれほど無いことがわかりました。

大北改二の所有数 提督数 最大 最小 平均 標準偏差
2 42 5900000 174700 1378459.5 1194011.3
1 14 1300000 43500 481650.0 362335.6
0 39 1600000 1500 312987.2 354371.6
総計 95 5900000 1500 808893.7 980487.1

うーん、このデータからは甲難易度クリアの十分条件はよくわからないですね。

雷巡改二の所有数、艦隊司令部レベル、攻略度の比較

これだと消化不良なので、最後に雷巡改二の所有数、艦隊司令部レベル、攻略度をすべて対比してみました。

表が大きくなったので、画像で貼り付けます。表中に「0+」とあるのは、0以上10未満と読んでください。レベル90台だけは詳細に表示しています。

こうやって眺めてみると、「艦隊司令部レベルが高ければ、雷巡改二がなくてもクリアできている」、従って「甲種勲章が欲しければとにかくやりこんでレベルを上げろ」というのが結論っぽいですね。

前段作戦

f:id:muziyoshiz:20170630004411p:plain

後段作戦

f:id:muziyoshiz:20170630004427p:plain

まとめ

今回は、Admiral Stats にアップロードされたプレイデータをもとに、後段作戦の甲難易度をクリアして甲種勲章をゲットするための十分条件を探ってみました。その結果、

  • 艦隊司令部レベルが一定以上になるくらい、やりこんでいれば甲クリアできた
  • 雷巡改二を2隻とも持っていると甲クリア率が上がるが、艦隊司令部レベルの方が寄与が大きかった
  • 逆に、雷巡改二を2隻持っているだけでは、甲クリアに十分ではなかった
  • 艦娘のレベルが低くても甲クリア可能だったが、艦娘のレベルが一定以上なら確実に甲クリアできた
  • Admiral Stats のユーザはやっぱりやりこみ勢が多かった

といったことがわかりました。

もう少し分析方法を工夫したり、プレイデータをアップロードしてくれる提督が多くなれば(やりこみ勢に偏っていなければ)、甲種勲章をゲットできる・できないの差がもっと正確にわかるかもしれません。

第3回イベント以降も同じようにプレイデータ解析してみるつもりなので、こういうデータを面白いと思う艦アケ提督はぜひ Admiral Stats を使ってみてください。

www.admiral-stats.com

職場ブログに書いた記事まとめ

2017年9月追記:
私は2017年7月末をもって GMO インターネットを退職しました。これは2017年5月31日当時の情報です。

2015年1月に現職についてから、職場のブログに色々と記事を書いてきました。四半期に1回のペースで、それなりにまとまった内容を書くことを心がけてます。

グループ会社のブログに寄稿することもあって、自分でもどこに何を書いたか思い出せなくなってきたので、自分のブログにまとめておきます。今後、記事が増えたらここに追記します。

DevOps

DevOps 関係の話題は継続的に追っていて、職場でも隙を窺ってツールを導入したりしています。新しいツールの話題に加えて、職場ブログでは(許可を得た上で)個人ブログではなかなか書けない泥臭い話題も書いています。

Embulk

recruit.gmo.jp

recruit.gmo.jp

recruit.gmo.jp

HashiCorp

recruit.gmo.jp

Habitat

recruit.gmo.jp

Ansible

recruit.gmo.jp

recruit.gmo.jp

プログラミング

関数型言語の苦手意識を克服したくて、Elixir を触って記事を書いたりしました。ブログのネタにはしていませんが、最近は Scala も勉強中(何度目かの勉強中)です。

Elixir

recruit.gmo.jp

recruit.gmo.jp

自社サービスの API

recruit.gmo.jp

recruit.gmo.jp

その他(API 設計、Hadoop)

グループ会社の Tech Blog に書いた記事です。Hadoop は業務でもかなり触っているのですが、職場にもっと詳しい Hadoop おじさんがいるので、記事にすることがあんまりなくて……。

techblog.gmo-ap.jp

techblog.gmo-ap.jp

GNU social (OStatus) 自体の仕様に関する情報源まとめ

f:id:muziyoshiz:20170430143245p:plain

(上のロゴは、何故か スペイン語版の Wikipedia にだけあった。本当に公式のロゴ?)

はじめに

Mastodon 大人気ですね。

僕もとりあえず mstdn.jppawoo.net にアカウントを取ってお互いにフォローし、どれくらいの時間差でトゥートが伝達されるのか観察したり、GitHub に公開されているソースコードを少し読んだりしました。

「Mastodon は分散型だ」とか「GNU social と互換性がある」という話を聞いて、一体どんなプロトコルなんだろう……と気になって少し調べたのですが、GNU Social 自体がかなり古いものらしく、ドキュメントを探すのにも苦労しました。

そこで、自分で探した範囲で、原典に近いと思われるドキュメントのリンク集を作っておきます。新しい情報が見つかったら、随時更新します。

プロトコル同士の関係

以下のドキュメントに書かれている、OStatus に関連するプロトコルをまとめると、次のようになります。

  • Atom と RSS フィードを、サーバ間の共通言語として使う
  • Webfinger を使って、サブスクライブしたい相手の Link-based Resource Descriptor Discovery (LRDD) ドキュメントを探す
    • Webfinger を使う前に、meta-data で Webfinger 用の URI を取得する。
  • サーバ間でフィードのアップデートを購読し、プッシュ配信を受けるために PubSubHubbub を使う
  • PubSubHubbub の機能不足を補うために、Atom の拡張(Activity Streams, Portable Contacts, Salmon)を使う
    • フィードが表す social activity を表現するために、Activity Streams を使う(例えば、フォローのときは "follow" verb を使う)
    • プロフィール情報を提供するために Portable Contacts を使う
    • リプライを送るために Salmon を使う

GNU social

OStatus は、GNU social にマージされた StatusNet に端を発するプロトコルです。そこで、まずは GNU social のドキュメントを当たりました。

  • GNU social - Wikipedia

    • 結論から言うと、GNU social そのものについては情報が失われていて、Wikipedia に載っている以上の情報はコードを読むしかないのかもしれない。
  • GNU social の公式サイト

    • 情報量はあまりない。
    • What is GNU social? に、GNU social が2010年に PHP スクリプトの集合として始まったこと、その後 StatusNet とコードベースが共有されたこと、2013年に Free Social project とマージされたことなどが書かれている。
    • FAQ にある "Why are you using PHP? Ruby/Python/Perl/A GUI in Visual Basic would be better!" の答えにちょっと笑った。
  • GNU social の GitLab

    • 最新版は 1.2.x 系。リリースノートもタグもないため、詳細はよくわからず。
    • 開発は継続されているが、Contributors のグラフ を見る限り、当初の開発者はほとんど手を引いている。
    • doc-src ディレクトリ にドキュメントがあるが、ざっと見た限り、クライアント-サーバ間通信の情報しかない。サーバ間通信の情報は見当たらなかった。
  • GNU social の GitHub

    • 上記の GitLab のミラー?
  • The Unofficial GNU Social documentation!

    • 基本的に GNU social のインストール方法についてのマニュアル。
    • Protocol Overview というページがあったので、これは!と思ってクリックしたら "GNU social runs primarily on voodoo magic. If anybody knows better please advise." としか書かれてなかった。
    • ですよね。

OStatus

  • OStatus - Wikipedia

    • OStatus の歴史と概要、OStatus を採用するソフトウェア一覧あり。
    • このページでは関連するプロトコルとして Atom, Activity Streams, PubSubHubbub, Salmon, Webfinger の名前が挙げられている。
    • "Standards Work" の節に、「pump.io で使われているプロトコルを元にした "ActivityPub" と呼ばれる新しい標準があり、これが OStatus の後継になりうるとされてきた」という記述がある。
  • OStatus Community Group

    • W3C のサイトにある Wiki。情報量は決して多くないが、OStatus に関連するプロトコルについての説明がある。
    • (see spec) と書かれた部分がリンクになっており、そこに OStatus 1.0 Draft 2 の仕様がある。
  • OStatus Community Group - Workflow

    • HTTPリクエスト/レスポンス例を伴った具体例。もしかしたら、これが OStatus のシーケンスに関する、最も詳しいドキュメントかもしれない。
    • ただし、これは OStatus 1.0 Draft 1(リンク切れ)ベースらしいので、Draft 2 とは多少違う可能性がある。
  • OStatus 1.0 Draft 2 の仕様

    • 2010年8月公開。
    • 全体で7ページと、仕様書としては短い。詳細を他の仕様書に譲っているからだが、参照先のドキュメントが古いため、一部はすでに見つからなくなっている。
    • 用語の定義があり、OStatus を調べる人には、それだけでも有用かもしれない。
    • OStatus では、プライベートメッセージングやソーシャルグラフは対象外、と書かれている。
    • "12. Usage scenario" に利用シナリオが書かれている。

meta-data (Web Host Metadata)

これは mstdn.jp で簡単に試すことができます。例えば、https://mstdn.jp/.well-known/host-meta にアクセスすると、以下が返されます。

> curl "https://mstdn.jp/.well-known/host-meta"
<?xml version="1.0"?>
<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
  <Link rel="lrdd" type="application/xrd+xml" template="https://mstdn.jp/.well-known/webfinger?resource={uri}"/>
</XRD>

Link-based Resource Descriptor Discovery (LRDD)

  • draft-hammer-discovery-06 - LRDD: Link-based Resource Descriptor Discovery
    • LRDD に関する最後の Internet Draft。
    • このプロトコルは、URI が示すリソースにアクセスするための「プロセス」を定義している。host-meta を使う方法は、そのプロセスの一つである。
    • host-meta を使う方法は "5.1. host-meta Document" に記載されている。

Webfinger

これも mstdn.jp で簡単に試すことができます。

LRDD が示すように "application/xrd+xml" を指定して https://mstdn.jp/.well-known/webfinger?resource=acct%3Amuziyoshiz%40mstdn.jp にアクセスすると、XML 形式で返されました。ちなみに、Web ブラウザでアクセスすると、JSON(application/jrd+json)が返されます。

> curl -H "Accept: application/xrd+xml" "https://mstdn.jp/.well-known/webfinger?resource=acct%3Amuziyoshiz%40mstdn.jp"
<?xml version="1.0"?>
<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
  <Subject>acct:muziyoshiz@mstdn.jp</Subject>
  <Alias>https://mstdn.jp/@muziyoshiz</Alias>
  <Alias>https://mstdn.jp/users/muziyoshiz</Alias>
  <Link rel="http://webfinger.net/rel/profile-page" type="text/html" href="https://mstdn.jp/@muziyoshiz"/>
  <Link rel="http://schemas.google.com/g/2010#updates-from" type="application/atom+xml" href="https://mstdn.jp/users/muziyoshiz.atom"/>
  <Link rel="salmon" href="https://mstdn.jp/api/salmon/14903"/>
  <Link rel="magic-public-key" href="data:application/magic-public-key,RSA.wOHgmclLfwfGDWfxN1pWfGIwr5GTXbFhJG49yuqrdI6T2WULDvlXUJx3vSIMCiwtkZn-DE9Rhpyse9_69xshlYerke0RvI6OfnvTv20RqFEz0Z65k9W4GTcYKAKu441OzMnY9C3144SiecDpW2noULukzFOMOEY22ON21yQk94QAzJXFt2Hh35ia31uK_JI5NDWGrcl-Rdl8mTHDjhkA4sZC504IInxEpMSxOMMhs75DS_HYYdYuWX-hkGtGEZy5qEfz7HSrSMU8x6e-hwq_ULZ-a5TmIWslJkqWoX_T94gR0hiLPEjpNQpf7R50jB57dltmeo_wKyeETkjxoWBRDw==.AQAB"/>
  <Link rel="http://ostatus.org/schema/1.0/subscribe" template="https://mstdn.jp/authorize_follow?acct={uri}"/>
</XRD>

PubSubHubbub (PuSH)

twitter.com

Activity Streams

Portable Contacts

Portable Contacts は、Google Contacts などでも使われている仕様らしいが、正式な仕様書らしきものが見つからなかった。

Salmon (Salmon Protocol)

The Good Stuff によると、「鮭が上流に泳いでいくように」元のブログサーバにコメントを送り返すためのプロトコルなので、Salmon という名前にしたそうです。OStatus では、これをリプライを返すための仕組みとして使っています。

OStatus が使っている、その他の Atom 拡張

番外:ActivityPub

OStatus の範囲外ですが、ActivityPub についても取り上げておきます。

まとめ

実際にドキュメントを追ってみて、噂に聞く通り、OStatus は非常に雑多な(一部はすでに廃れた)プロトコルの組み合わせで作られていることがわかりました。それぞれのプロトコルが、Mastodon 上でどう実装されているかは、他の人の調査に任せたいと思います。

実際、OStatus について先行して調べていた岡本さんによると、GNU social などの既存実装は、これらのドキュメント通りに実装しても動かないそうです。

twitter.com

OStatus について、5月12日に出る(早い!)マストドン本で岡本さんが解説してくれるらしいので、とりあえず僕はこの本を待とうと思います。

okapies.hateblo.jp

これがマストドンだ!  使い方からインスタンスの作り方まで (NextPublishing)

これがマストドンだ! 使い方からインスタンスの作り方まで (NextPublishing)