そして3人になった

皆さん、こんにちは！

グレッグ・デニスです。私はjson-everythingの作者です。これは、JSON Path、JSON Patch、そしてもちろんJSON Schemaなど、.NetにおけるJSONニーズに対応する包括的なツールスイートを目指しています。また、JSON Schema仕様における出力要件の策定と作成も担当しています。

ジュリアンさんのニュースに便乗して、私もPostmanに入社し、仕様とツールアーキテクトとしてJSON Schemaに専念することになりました！つまり、私は仕様の更新に取り組むと同時に、検証やその他のJSON Schema関連ツールの定義と実装を支援することになります。また、他のツール実装者をサポートすることで、コミュニティにも深く関わっていく予定です。

関わるということ

JSON Schemaは、私にとって常に情熱を注いできたプロジェクトです。仕事では*実際には目にすることはなく、JSON Schemaが解決策となる問題に直面したこともありませんでした。それでも、JSON Schemaが他の人々にとって必要な解決策に*なり得る*可能性を感じ、導入しやすい道筋を提供することで貢献したいと思いました。

* *私は主に.Netの世界で仕事をしてきました。そこには多くのデータ検証ツールがあり、そのほとんどはフレームワークに組み込まれており、デシリアライゼーションを中心としています。しかし、JSON Schemaの人気が高まっていることから（特にコード生成の分野で）、.Netでもすぐに適切な場所が見つかるでしょう。*

私がJSON Schemaに初めて関わったのは2015年、自分のライブラリであるManatee.Jsonに実装するJSON関連の機能を探していたときのことです。JSONデータを検証できる機能が気に入りました。特に、検証要件自体をJSONで表現できる点が気に入りました。

当時、Draft 4は公開されてから数年が経過しており、プロジェクトはほぼ放棄された状態から再び立ち上げられようとしていました。当時は知りませんでしたが、私はちょうど良いタイミングでプロジェクトに巡り合ったのです。公開されているissueを読み始め、いくつかコメントを付け、Slackワークスペースに参加しました。

すぐに私がいなくなることはないだろうと分かり、チームのコアメンバーとして貢献するよう招待されました。私は、JSON Schemaのユーザー（主にスキーマ作成者）にとって特定の機能がどれほど役立つか、使いやすいかと、その機能を実装するのがどれほど難しいかとのバランスを取りながら、変更や新機能について議論することに余暇を費やしました。

それ以来、私は数え切れないほどの議論に参加し、仕様の変更についてコメントし、前述の出力フォーマットのセクションなど、私自身もいくつか作成に貢献してきました。

JSON Schemaに関わることで、多くのことを学びました。

最も重要なのは、相互運用性に重点を置くことで、私が使ったことのないプログラミング言語やフレームワークのニーズに目が向いたことです。主にC系言語で作業していたため、異なるプログラミング言語が実際に異なることを*できる*とは考えてもいませんでした。以前は、異なる言語はすべて同じ機能を提供しており、違いはタスクの難易度だけだと考えていました。

また、JSON Schemaは検証だけでなく、ハイパースキーマ、コード生成、フォーム生成など、さまざまな用途に使用されていることも学びました。アプリケーションの多様性は、JSON Schemaを素晴らしいコンセプトにしています。

実装者であるということ

私は（これまでに）JSON Schemaを実装したライブラリを2つ持っています。

Manatee.Jsonが最初で、これは私のコーディングスキルを向上させるための学習プラットフォームと、実際に人々の役に立つことを意図したものの半分でした。決して速いものではありませんでしたが（後に、自作のパーシングが遅いだけだと分かりました）、仕様には忠実で、nuget.orgのダウンロード統計ではそこそこの成績を収めていました。この記事を書いている時点で、非推奨になってから2年が経過しているにもかかわらず、1日300回ダウンロードされ続けており、累計100万ダウンロードを達成しています。

2つ目のライブラリであるJsonSchema.Netは、2020年にリリースされ、より実用的な本番用ライブラリを目指しています。これは、2019年にリリースされた.Netの新しい組み込みSystem.Text.Jsonパーサー/シリアライザーのJSON Schemaコンパニオンとして作成しました。公開されてから2年間で、1日あたり約670回のダウンロードがあり、累計で45万ダウンロード近くに達しています。

JsonSchema.Netには、.Netコードからのスキーマ生成、スキーマからのデータ生成、仕様リポジトリの未解決のGitHub issueに対処するために私が作成した2つのボキャブラリー（外部データアクセスと、指定されたキーによる配列内での項目の一意性の識別）など、追加機能を提供する「拡張パック」ライブラリもいくつかあります。

JSON Schema（そしてJSON全般）の拡張用途を常に探しており、スイートに追加しています。そして今、それを行う時間が増えました！

従業員であるということ

昨年、BenがJSON Schemaに専念するためにPostmanに入社すると発表したとき、私はプロジェクトの方向性について懸念を抱いていました。Postmanはプロジェクトを所有しようとしているのでしょうか？それはプロジェクトの将来や、私たち（ボランティアの貢献者）が変更を実施する能力にどのような影響を与えるのでしょうか？

Benの回答は素晴らしく、完璧なものでした。彼はJSON SchemaがOpenJS Foundationに参加することを支持し、その独立性を確固たるものにしました。そして、彼がPostmanの従業員でありながらそれを行ったことは、Postmanがオープンソースコミュニティの改善のために尽力していることの証左となりました。

その後、業務は通常通りに進められました。私たちは皆、2020-12（現在はリリース済み！）の編集上の、機能的でないパッチリリースに向けて懸命に取り組んでおり、Benはより専門的な支援が必要だと感じました。そこで、SlackのDMで、私に一緒に参加することに興味があるかどうか尋ねてきました。新しい会社に落ち着いたばかりでしたが、この機会を逃すことはできませんでした。情熱を注いでいるプロジェクトに携わって給料をもらえるなんて、夢のようです！

そして今、私はPostman Open Technologiesに仕様とツールアーキテクトとして入社することを非常に嬉しく思います。私は3つのことに焦点を当てます。JSON Schema仕様の策定、実装者へのサポート、関連用途の開発サポートです。

まず仕様について、出力フォーマットは引き続き私にとって主要な焦点となります。今年の初め、私は潜在的な改善点について議論を開始しました。良い方向に進んでいると思いますし、仕様書にある現在の記述を新しい設計に移行するためのPRを作成し始める必要があります。

実装者サポートがどのようなものになるかはまだ分かりませんが、実装ページを見ると、多くはまだ2020-12をサポートするように更新されていないようです。アウトリーチは、ここで始めるのに最適な場所でしょう。これらのプロジェクトのそれぞれの状況を知る必要があります。まだメンテナンスされているのでしょうか？仕様に沿って最新の状態を維持する*つもり*はあるのでしょうか？助けが必要でしょうか？これらの質問に答えることが最初のステップになります。

そして最後に、関連ツールです。JSON Schemaが現実の世界でどのように使用されているかを目の当たりにすることができ、それによってその有用性を*検証*（！）できるため、この部分に非常に興奮しています。

Postmanが私に、私が愛するプロジェクトとその周辺にフルタイムで取り組む機会を与えてくれたことに非常に興奮しており、このプロジェクトとそれを支え、構築し続けるコミュニティの明るい未来を予感しています。

この旅で出会ったすべての人、私のライブラリを使ってくれた人、質問してくれた人、コードを提供してくれた人、あるいは意見をくれた人に感謝します！このコミュニティの一員であることを嬉しく思います！

カバー写真は私です 😁