2024-09-28

JSONと名のつく仕様に関して、観測できる範疇でざっくり表にしてみる

種類がいくつかあるので書き出してみる。

ざっくりまとめ

大きくは

JSONに仕様を機能拡張したもの (json5,jsonc)
JSONのオブジェクトを1行単位で処理できるようにしたい仕様追加(jsonl,ndjson)
JSONをつかって違うことを表現するための仕様(json-ld,geojson)

というようなカテゴライズになる。

名前	どういうものか	仕様など	拡張子の例
json	基本となるJSONの仕様。	RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format	.json
json5	JSONから拡張されたもの。	JSON5 – JSON for Humans \| JSON5	.json5
jsonc(JSON with Comments)	JSONからコメントをかけるようにしたもの。VSCode用のものが主流と思われる。	GitHub - microsoft/node-jsonc-parser: Scanner and parser for JSON with comments.	(明確な拡張子の記載がない)
jsonl(JSON Lines)	1行1オブジェクトで構成されるJSON	JSON Lines	.jsonl
ndjson	jsonlの派生、オブジェクトを1行で書きたい。	GitHub - ndjson/ndjson-spec: Specification	.ndjson.
json-ld(JSON for Linking Data)	Linked dataをJSON形式で記述するための仕様	JSON-LD - JSON for Linking Data	.jsonld
GeoJSON	地理データ（GISデータ）をJSONで表現するためのフォーマット	RFC 7946 - The GeoJSON Format	,json , .geojson

イベントストーミングに関してざっくりまとめる

ざっくりまとめ

とりあえず王道の流れをさまざまな資料からざっくりまとめる

原典

EventStorming

起源

2013年頃にAlberto Brandolini氏が下記ブログで提唱した考え方

Ziobrando's Lair: Introducing Event Storming

概要

付箋の色ごとに意味を持たせて張り出して、業務に詳しい人（いわゆるドメインエキスパート）とコミュニケーションしながら情報を整理するワークショップ形式の手法。付箋の色と意味は以下の通り。

ざっくりとしたやり方

主に以下の3ステップで作業を行う。

STEP1. ドメインイベントの収集（BigPicture) STEP2. プロセスモデリング STEP3. ソフトウェアモデリング

STEP1. ドメインイベントの収集

DomainEventの付箋（オレンジ色）を業務に詳しい人と貼っていく。イベントが発生する順序に貼っていきイベントの流れを貼り出していくプロセス。すべて貼り出したら書いている内容に関して時系列が正しいか、それぞれの付箋内の言葉に揺れがないかなどを見て整理していく。

STEP2. プロセスモデリング

イベントがどこ起因で発生するのかを整理していく。ユーザが起因となるもの（Commandとそこに関連数ActorとView）、外部システム、時間軸で発生するようなもの（Policy）、別のDomainEventなどを貼り出して起因となる要素を洗い出す。

STEP3. ソフトウェアモデリング

最後にDomainEventをグルーピングしてコンテキストを整理します。これによりDomainEventがどのような塊にって、どのような境界があるのかが明らかする。これでDomainEventをどの粒度で扱うべきか、どのようなイベントが全体的に起きるのかが可視化されお互いの共通認識を得ることができるようになる。

参考リンク

2024-09-14

グッドハートの法則に関してざっくりまとめる

ざっくりまとめ

原典

イギリスの経済学者、チャールズ・グッドハート氏の論文に登場する以下の内容がもととなったもの

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.

観察される統計的規則性は、制御目的で圧力が加えられると崩れる傾向があります。

元の話はどういう意図のものなのか

いままで観測されてきた統計データに関して、それをもとにして何かしらのアクションが起こされるとその規則性は崩れるというもの。主に過去の計測データとそれに対する政策に関しての話としてつかわれており、規則性に対して何かしら政策アクションをかけるとその規則性はなくなってしまう。

こちらのページにて紹介されている例だと「結婚指輪の購入数と結婚の数に関連があるという統計データ」があるとしたときに、結婚数を減らしたくなったときに「結婚指輪の価格をあげる」という政策をとっても規則性が崩れるだけ、というような話。

どのように捉えられるようになったのか

別の話題として、心理学と社会学のアプローチとしてキャンベルの法則があり、こちらは簡単に説明すると「能力を測るのペーパーテストを使って点数をつけるが、点数そのものが目標になる（≒高得点を得ることが目的）になると計測としての効能は失われる」というようなもの。

このような考えと絡めて「計測される指標自体が何かしらの目標などに据えられるとその計測指標自体が意味をなさなくなる」という意図で使われている。

現在ではどのように使われるか

主に目標設定の文脈で語られることが多く、本来達成すべき話題から間接的に設定された数値などに対して、意味のない操作を行うことが起きる文脈で使われる。

たとえば目標設定で「売上をあげるために、契約数をいままでの2倍にします」というように設定すると、いままでは包括して行っていて契約を分割契約にしてあたかも件数が増えたようにするが、本質的には契約で取り交わされている金額が変わっていない、というような話で使われる。

参考リンク

2024-09-07

「イミュータブルな変数」という言葉をざっくりまとめる

ざっくりまとめ

そういえばなんとなく雰囲気で使っているところがあるので

immutableとは

英単語としてのimmutableは「不変の」というような意味。

Immutable Object

オブジェクト指向の文脈で Immutable Object というフレーズがある。これはオブジェクト指向におけるインスタンスを生成したタイミング以降は状態が変化しない（不変）のオブジェクトのことを指している。

具体的には各オブジェクトがインスタンス変数として持つ値は、インスタンスの生成後は変更や操作できないようになっているような構造のオブジェクトのことを指す。とても大雑把に表現するとsetterなどのインスタンスの内部の情報を書き換えるような変数を持たず、それらの値はインスタンス生成時に設定されて変更が効かないオブジェクトなどがこれにあたる。

イミュータブルなオブジェクトは内部の状態が変化しないので、変化したことを考慮した実装が減るという利点がある。

イミュータブルな変数

Immutable Objectの考えの延長線上に、一度定義したら内容の変えない変数をイミュータブルな変数という表現をすることがある。

多くは一度変数を定義したら、定義時点の情報から書き換えない（再代入や操作を行わない）変数のことを指す。プログラミング言語によってはイミュータブルな変数として定義できるようになっている（Swiftのletなどがこれにあたる）。もちろんプログラミング言語などでイミュータブルな状態を維持する機構がない場合もある。