JSON Schema Draft v.4の規格書を読む
2016年1月5日現在において、JSONを受け取り、返却するWeb APIを書くときに、人が作った規格に乗って楽をしようぜと考えた。 その過程で調べた、JSON Schemaについてメモ書き。間違ってたらツッコミよろ。 概要 JSONの構造を記述する規格。構造の記述そのものもJSONで書かれる。 Draft v4現在では、JSON Schemaは以下の3つの規格の総体を指す。 JSON Schema Core JSON Schema Validation JSON Hyper-Schema そもそも提案された初期のJSON Schemaは、JSON Schema Core+JSON Schema Validationとほぼ同じ領域をカバーしていた。整理・発展の上3仕様に分割された。よって、JSON Schema Core+JSON Schema Validationにあたるものを単にJSO
危なくないgitこと、うちのチームのgit戦略草案(ver. 1)
この記事は更新された版があります 2012/11/16: いただいたフィードバックをもとに、version 2を書きました。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常用しているような環境です。 gitは、以下のように使えば安全です。 mergeに相当する操作をしない rebaseに相当する操作をしない …悪い冗談。極端な話ですね。しかし、「merge/rebaseの回数を減らせば、トラブルが起こる確率を減らすことができる」というのは事実です。 そこで、GitHub(Enterprise)の利用を前提に、こう
JSON on HTTPやWeb APIを各言語でどうやって実装するのか
HTTPでアクセスして、JSONを返すようなWebサーバを書きたいとする。 どんな言語を選ぶか。どんなミドルウェアを選ぶか。どんなライブラリを選ぶか。 たとえば、TIOBE Softwareが公表している「Programming Community Index(PCI)」という指標がある。人気のあるプログラミング言語の数値化。これを見ていて思ったのは、「多すぎだよね、プログラミング言語」ということ。これらのうち、どの言語を勉強し、どの言語をプロジェクトに採用すべきなのか。 その感触を得るために、 「同じ仕様のREST serviceを複数言語で実装したらいいんじゃね？」 と思った。いくつかの言語で実装を起こしてみている。 前提条件 大規模な開発を想定する。ユーザの規模が大規模。トランザクション数が大規模。そして、開発者が大規模。 実用的かつモダンな開発を想定する。プロジェクト毎のバージョン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
