ブログがスランプっていうか一本前のMicrosoft Build語り記事のせいでペースが、ペースとおまんこが壊れそう。両方同時にパリンと音を立てて壊れそう。チマチマ追記してるんだけど情報量が大きすぎてキッツイ。聞いたことだけ書くんならサクサクだが、疑問点を解消しつつのアウトプットですから時間がメリメリ溶ける。それゆえブログが硬直しかねん。

というので、書くほどでもないようなことを整調のためにペチペチ書く。アホほどどうでもいい乱文でお届けします。途中からIT技術の話になります。だから帰れ。

◆趣味

世界平和を実現する（正確には不当に悲しんでいる人を減らす）ための方法について考えるのが趣味でして、実現にはインターネットを利用するほか道がない。

インターネット上に何らかのサービスを構築する必要があって、そのサービスの設計について自動的に考えるように脳がなってる。面倒なので実際に作りはしないけど。

大項目として「悲しんでいる人を減らしたい人やらそれ以外の人やらがワーワー集まって便利に使えるツールっぽいSNS」を作ればいいんじゃねぇかという話に脳内会議で多分5年くらい前に固まって、その詳細について俺の脳内PCが演算をし続けている。

考えすぎてわけわからんことになりつつあり、歩みだしでいったらエロサイトから始まる気がする。なぜなら世界最強の集客コンテンツがエロか金かだから。平和活動に人は集まらない。人を巻き込めない。

◆テキストフォーマット

頭の中で思考をぶん回しているだけなので、世界平和とは全くもって関係のない詳細部分についてハナシが展開されていくことがよくある。いまのブームがテキストフォーマット。

【再々考】テキストデータフォーマット考える

トイレしてるときとか淹れたお茶を眺めているときとか寝る前とか歩いているときとか、脳の計算リソースを半分くらい割り振ってこのフォーマットについて考えている。勝手に。自動で。俺の意思とあまり関係なく。

このSenと仮命名したフォーマットは、JSONとかCSVに制限を加えて使いやすくしたいみたいな動機で考え進めている。

今考えている仕様ではテキストファイルのトップレベルがオブジェクトなんすよね。例えば一冊の絵本のデータは以下のように表現される。

>title: "ねないこだれだ"
>price: 770
>isbn: "978-4834002188"

（一番簡易に書くと）こんな感じ。これが書かれているテキストファイルひとつで本一冊を表現する。1レコード。似た構造をJSONで表現すると

{
  "title":"ねないこだれだ",
  "price":770,
  "isbn":"978-4834002188"
}

こう。

◆プロパティ名重複

Senでは重複したプロパティは後勝ちになるんですよ。ファイルの先頭から解釈されていって、後に書かれていることを優先する。

だから、price、つまり価格が二度記述される以下のケースでは、価格は880円と理解される。

>title: "ねないこだれだ"
>price: 770
>isbn: "978-4834002188"
>price: 880

この仕様について

手でオブジェクトの内容を書き換える際、書き換えたつもりが書き換わらない。なぜなら同名プロパティが後方で記述されているから。

みたいな事象がデメリットとして発生しうるんだけど、それはエディタでアラートあげろやと思っている。記法としてエラーにしたところでどうせ気づけないんだよな。例外で落としたい気持ちもあるけど、実際に享受できるメリットが思ったよりか小さく思える。

追従する気はないけどJSONでも後勝ち。…だったような。キー重複禁止はSHOULDとかだった気がする。

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique.

RFC 8259 – The JavaScript Object Notation (JSON) Data Interchange Format (ietf.org)

あってた。

An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.

RFC 8259 – The JavaScript Object Notation (JSON) Data Interchange Format (ietf.org)

実装依存すね。

とにかくSenに於いては後勝ちでよかろうと、そう思っていた。

◆データの更新

JSONデータの運用についての話をする。

例えば町の書店が書籍管理システムを持っていたとして、さっきのJSONがデータベース（ドキュメントDB）に格納されている状況を考える。

{
  "title":"ねないこだれだ",
  "price":770,
  "isbn":"978-4834002188"
}

この本の価格変更があったとき、上記データ（実態としてテキストファイル（語弊あり））に対してどういう操作を実施するべきだろうか。

「テキストエディタでもってファイルを開いて書き換える」みたいな話もあるんだけど、実際のシステムではデータベースっていう「データ格納を専門とするパソコン（語弊あり）」に対して「更新してくれ」みてぇに命令するノリで操作するんです。

JSONを格納するデータベースに対してあるプロパティの更新を命令するときは、JSONそのもの、つまりデータの全量を渡してやる必要がある。部分的に書き換えることが難しいから。難しいっていうか面倒だから。

価格の情報だけ渡すんじゃなくて本の情報全てを渡し、データベースに対して丸ごと上書きするように指示する。

それはそれで正しい。価格だけ書き換えるのは面倒。来たデータを解釈するのも面倒。全部置き換えたほうがマシ。問題も起こりづらい。

◆えうれか

でSenに戻るんだけど

>title: "ねないこだれだ"
>price: 770
>isbn: "978-4834002188"
>price: 880

これ…

これヤバいよね。格納されているSenの最後に行を追記してやるだけでデータの更新が成る。いや、実際は行じゃなくていい。Senは改行も空白も無視する。ケツにぶっ刺すだけでいい。

>title:"ねないこだれだ">price:770>isbn:"978-4834002188">price:880

これをよ。夜寝る前のまどろみにてこの事実に気づき、驚愕し、まず目を開いてしまった。部屋は真っ暗。次に心臓がドキドキし始め、居ても立っても居られなくなり上体を起こした。ドキドキしすぎて眼鏡をかけてしまった。呼吸が荒くなった。本当に。誇張なく。

アルキメデスとかニュートンが体験したと噂される「めっちゃ気づいた時のやつ」が俺の脳に発生したのだ恐らく。

▼解説

クライアントからDBに投げるデータが小さくて済むな。データの全量をいちいち渡さずとも、更新のあったプロパティとレコード識別子（例に沿っていえば本のISBN）だけで事足りる。HTTPなら識別子はURLに入れりゃいい。HTTP PATCHってこれのことを言ってたんじゃないか。

更新指示を受け取ったDBは、もらったものをそのまま連結するだけで更新が終わる。半ば非破壊で、メモリにも優しい。各方面のメモリや帯域にやさしい。更新が嵩みすぎるようなデータには不向きであるケースもあろうけど。

記法的に汚いってこともない。つまるところ台帳なんです。紙の台帳に支払い情報を書き込むとき、「もともと持っていた金額」の情報を消して減った分で上書きするようなことはしないだろ？支払った情報を書き込んで、最終的に合計金額を算出するはずだ。

台帳データのほうが堅牢で耐障害性がある。と個人的には思っている。ただし現在の状況を知るためには都度の計算が必要にはなる。とはいえ台帳的にやるかどうかは選択できるから好きに判断しろよって感じ。選べるから最適化もできる。新しいキャッシュ戦略も考えられそう。

変更したタイミングとか変更者の情報をプロパティ情報と共に記述したい気はする。ドキュメンテーションコメントについて考えていたから、その考えと合流させればいいだろう。

バックエンドから手元にファイルをひっこぬいてきたとき、状況が分かりにくいってことはありそう。とはいえファイルの最後からみて一番初めに来るやつを見るだけだ。あるいはなんらかのエディタで開いて解釈してもらえや。

ドキュメントDBのバッチ更新ってつらみがぴえんだったじゃん？その辺も大解決ですよね…🥺。配列に対しては引き続き難しいものがあるけど、階層構造でも問題ない。新しくプロパティ増やしたいときも楽勝で初期値を設定できる。

◆結

そんなことで一人ワクワクしていた。ワクワクしていたのでMicrosoft Build語りが仕上がるまではもう少し待ってください。

…誰も待ってないか。独り相撲だった。