コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

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をどの粒度で扱うべきか、どのようなイベントが全体的に起きるのかが可視化されお互いの共通認識を得ることができるようになる。

参考リンク

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

原典

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

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

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

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

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

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

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

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

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

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

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

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

参考リンク

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

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

immutableとは

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

Immutable Object

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

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

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

イミュータブルな変数

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

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

参考/関連リンク

組み合わせ爆発についてざっくりまとめる

日本語特有の表現かと思ったらそうではなかったのでメモ

意味

問題を解く過程にある、内容のかけ合わせが増大する事例のことをいう。

組み合わせのかけ合わせが増えれば増えるほどパターンが増えるという事例は下記を見ていただくとわかりやすい。

『フカシギの数え方』 おねえさんといっしょ! みんなで数えてみよう! - YouTube

語られ始めた時期

英語版のWikipedaで初めて記事が作られたのが2006年、その前年の2005年にも "combinatorial explosion" の記載がある論文がちらほらあるので、その頃から出てきた言葉かと思われる。

関連するフレーズ

指数関数的に増える(指数関数的増加)

指数関数は線形的な関数に比べて、数の上がり方が急激に増えるため、その性質になぞらえて指数関数的〜という表現がされる。

こちらに関しても下記サイトで図が紹介されているので参照のこと。

増え方に着目してみよう ~ねずみ算と指数関数~

参考リンク

2024年夏頃時点のmiroでは、ふきだしのしっぽがコントロールできる図形はcalloutで検索すると出てくる

自分自身が困ったのでメモ

miroの吹き出し図形の難点

miroの下記の部分にある吹き出し図形は吹き出しの発言者の三角形、いわゆるしっぽやツノと言われる部分がPower PointやGoogleスライドのように操作できない。

callout(ふきだし)を使う

しっぽの部分を動かしたい場合はデフォルトのリストにあるものを選ぶのではなく、callout(あるいはふきだし)で検索して出てくるものを使う。以下の図のようなイメージ。

参考リンク

モデルなどの関係性を表すときに使うCrow’s foot(カラスの足)記法についてざっくりまとめる

記法の名前もよくわかっていなかったのでメモ書きレベルで

起源

Gordon C. Everest氏の1976年の論文を起源にしており、"Crow's foot"という呼称に関してもあとから付いた呼称である。日本ではIE(Information Engineering)記法とも呼ばれることがある。

使い所

オブジェクトとオブジェクトの関係性を表すときに用いられる。お互いの存在に対して0、1、1以上の関係性が表記されている。

関係性を表す際に以下の図形で表現する。

線の一覧

使い方例

下記のような図の使い方になる。

使い方例

参考リンク