TRPGキャラクターシートの管理のこれから
この記事はTRPG なんでも Advent Calendar 2018の24日目の記事です。 こんにちは。まだまだTRPG初心者(クトゥルフPL2回、アマデウスPL1回)の@acomaguと申します。プログラミングをたまにします。 今回はキャラクターシート置き場についての話をします。自分はクトゥルフTRPGのキャラクターシートをキャラクター保管所さんで管理しているのですが、キャラクターシートを保存できるサイトは他にもいくつかあります。 TRPGキャラクターシートアーカイブスさん とらぷぐ.comさん オンセンSNSさん …などなど。(クトゥルフ以外だとまたいろいろあるみたいですね) まあ言うほど無いんですが、それでも選択肢があります。ただ、ほとんどの方は自分と同じくキャラクター保管所さんを使っているような気がしています(あくまで自分の観測範囲ですが)。理由を考えると、いろんなサイトで推奨されているとか、数多くのTRPGに対応している、技能値の割り振りがしやすいなどがあると思います。 自分もそこそこ満足していたのですが、何度かアクセスするうちに不満点も見えてきました。「連携できるツールが少ない」ことです。 チャパレさんなど一部のツールはキャラクター保管所さんからの読み込みに対応していますし、キャラクター保管所さんのほうではどどんとふ連携に対応しているのですが、他のほとんどのオンセツールなどでは自分で能力値と技能値を手入力する必要があります。また、クトゥルフWebダイスさんのようなキャラクター作成ツールからの読み込みにも対応していません。このあたりの連携ができるサービスが見つからないのは、キャラクター保管所さんがキャラシートに書き込むためのAPIを提供していないことが原因と考えられます。 「ダイスを振る → キャラクターシートに保存する → オンセツールに表示する」までを一度も手入力することなくやりたかったのです。 このあたりのしんどさを解決しようと以下のようなツールを作ってみたりもしました。 acomagu/cstoml: TRPGキャラクター保管所 -> TOML キャラシートをパースしやすく人間も読み取りやすいTOMLに変換し、GitHubで管理しようという発想でした。しかし例えば能力値が変更された際にオンセツールが自動でGitHubにコミットを投げるというのも考えづらく、連携のしやすさという点ではこちらも貧弱なものでした。 また、単にキャラクターシートのデータを取得/更新できるだけではなく、リアルタイム性も担保したいと考えていました。というのも今後GMをやる上で、PL全員の能力値の現在値をまとめて閲覧できるビュワーがほしいと考えていたからです。単なる保存場所としてのWebサイトとは一線を画したものが必要でした。 そこまで考えて、私は Solid が解決策になるのではと気づきました。 Solidとは ちょっと一言で表すのが難しいのですが、もし無理やりその一言を選ぶのならばやはり「データをユーザの手に取り戻す」でしょうか。 仕組みを大まかに説明すると、ユーザーはサービス提供企業それぞれに個人情報を提供するのではなく「Solid POD」と呼ばれる保管場所（クラウドあるいは自分のサーバ）上に情報を保存し、Solid上のサービスを使う際、どの情報をサービス側に提供するかを選択する。これにより、ユーザーが自分の情報を管理しやすくなるだけでなく、サービスを利用した際に生じる個人データもアプリと分離されてPODに保存されるので、サービス側も大量のデータを収集する必要がないという（Solid Explainedページより）。 気になったエンジニアの方はぜひ公式サイトのMake a Solid app on your lunch breakをやってみてほしいのですが、結構面白いです。 以上のような特徴により、Solidは今までWebアプリケーションの背後にあったユーザのデータを、別の場所(=POD)に切り離して管理できるようにします。 そしてこのSolidを単なる理想論から現実に近づける特徴が「標準化された技術でできている」ことです。 Solidは大雑把に言って2つの標準を使用しています。まず1つがWebIDです。ユーザは自由にPODを乗り換えることができますが、ユーザがPODを変えてもユーザのデータのURLは変えない仕組みと言えます。1 そしてもう1つがRDFです。これはアプリケーション間のデータの形式の差異の最小限にするためのものです。GoogleカレンダーがPODに正しく予定を保存してくれていれば、その情報がYahoo! カレンダーでもそのまま開けるということですね。 なるほど… ではこのSolidをTRPGのキャラクターシート置き場に利用すると、何が起こるのでしょうか。 キャラクターシートをSolid PODに保存すると何が起こるか 「キャラクターシート置き場にSolidを利用する」ということは「キャラクターシートをSolid PODに保存する」ことを意味します。 こうすることで何がどうなるのか、もしすべてのサービスがSolidに対応していたと仮定して、使い方をシュミレートしてみたいと思います。 まず、ユーザはキャラクターシートを作成するために「クトゥルフWebダイス」さんのようなサイトでダイスを振り、能力値を決めます。ついでに技能値やキャラクター名も決めたところで保存ボタンを押すと、Solid PODに保存されます。 ユーザはそのまま好きなオンセサイトに移動すると「PODに保存されたキャラクターシート一覧」が更新され、先程作ったものが選べるようになっています。 こんな感じです。書き込みも読み取りも、初回はWebIDの入力と権限の確認があるでしょう。 データとアプリケーションが粗結合になったことでそれぞれのサービスの相互の対応の可否を気にする必要がなくなりましたし、開発者としてもSolidのみに対応することでよくなりました。 また今までは、例えばオンセなどでは「外部サービスからのインポート」と「自サービスのDBからの読み出し」を別の機能として実装していたのが、「Solidからの読み出し/保存」に統一されることで開発の負担も減ることが予想されます2。 更にSolidはリアルタイム更新対応です3。 そしてそしてすべての情報は予め定まった「キャラクターシートの規格」に沿って保存されるため、他のどんなアプリケーションでも同様にデータを認識することができ、ユーザは好きなサービスに乗り換えやすくなることでしょう。
git push origin masterを絶対に手打ちしないために
この記事はAizu Advent Calendar 2018の10日目の記事です。 雰囲気でシェルをやっているクソザコです。 $ git push fatal: The current branch master has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin master 初回にgit pushを打つとこのようなエラーが出ますよね。このメッセージどおり git push --set-upstream origin master と打てば二回以降は origin/master をデフォルトとして扱ってくれます。 が、Gitの言うがままにタイプしていては、リーナス・トーバルズに負けたということになってしまいます。 そこで自分はこんな感じにプロンプトを出すようにして今の所満足しています。 —追記— git push origin HEADでローカルブランチと同じ名前のリモートブランチにpushできるよ！ -uのときも使える — そな太@GraphQLの記事を書くぞ (@sonatard) December 21, 2018 まじで!? と思ってドキュメントを確認したら本当に書いてあった。 なんというか、HEADはローカルのリビジョンを指すときのみに使用できるイメージがあったので、これには驚きだった。 ちゃんとこんなふうに書いても動く。 git push origin HEAD:HEAD ちなみにちなみにHEADの内容をそのまま展開しても動く。 $ cat .
てすと
てすてす