構造化ログのフォーマット logfmt vs JSON lines - methaneのブログ
構造化ログのプラクティスをあちこちで調べていたら、logfmtを推奨する記事を見つけたので調べてみました。 先に結論を言うと、JSON linesを使っておくのが良さそうです。 logfmt について logfmtとはスペース区切りで key=value を並べたフォーマットです。文字列にはクォートとエスケープによってスペースや改行を含められます。 at=info method=GET path=/ host=mutelight.org fwd="124.133.52.161" dyno=web.2 connect=4ms service=8ms status=200 bytes=1653 (logfmt から引用) あちこちで logfmt のリファレンスとして紹介されているのはこの記事です。 https://brandur.org/logfmt 発明されたのはどこか分かりませんが、流行
JSONの差分を取ってJSON Patchを得るにはdiffsonがおすすめ - Lambdaカクテル
こういうツイートを見た。 Scala (or Java) で、jsonのdiffをpatchファイルみたいな感じでわかりやすいテキストで出力してくれるライブラリないかなあ。そしてjacksonに依存してないといいな— Arthur (@Arthur1__) 2024年1月13日 現代のプログラミングではJSONの差分を取ったり、逆にパッチを当てるということがよくある。可能ならそれがPretty Printできると良い。 JSONの差分をScalaで取る方法についていくつか調べてみたのでメモ。 JSONの差分をどう表現する？ JSON Patch diffson diffsonでJSON Patchを生成する diffsonでJSON Patchを適用する diffsonでJSON Merge Patchを生成する diffsonでJSON Merge Patchを適用する JSON Pat
Ruby の JSON ライブラリ Oj のパフォーマンス改善を行いました - Repro Tech Blog
Development Division/Repro Team/Feature 1 Unit の Watsonです。Feature 1 Unit は Repro Tool の機能開発と保守を担っています。 弊社でも利用している Oj gem のパフォーマンス改善 PR を送った話と、その PR の内容について共有します。 ことのはじまり 以前、同僚が Ruby on Rails で JSON を返す REST API を作成した際、JSON のエンコード部分のパフォーマンス計測をしていました。JSON のエンコード方法は JSON.generate、ActiveSupport::JSON.encode、Oj gem を利用する方法など色々ありますが、私としては Oj gemの ほうがパフォーマンス的にいいだろうからそちらを利用したほうが良いのではと思っておりました。 計測結果を拝見したら確
メモリに乗り切らない巨大配列のシリアライズにCBORフォーマットを採用した - Qiita
TL;DR 要素数が分からず、メモリに乗り切らない可能性がある配列をシリアライズする必要があったので、フォーマットとして CBOR を採用した。 Protocol Buffers1 や Ion, MessagePack, BSON などの主要なバイナリフォーマットで配列を扱う場合、要素数またはバイト長を先頭などに記述する必要があるため、メモリに乗り切らず要素数が簡単には分からない配列を（単純には）シリアライズすることができない CBORは要素数不明の配列を表現する手段がある Java/Kotlinの場合、jackson の jackson-dataformats-binaryを利用してストリームパーサ等を実装することにより、データすべてをメモリに乗せずにシリアライズ・デシリアライズすることができる jackson-dataformats-binary ではシリアライザ等の実装を JSON
「YAMLの本来の使い方」を仕様から読み取ってみる | Wantedly Engineer Blog
YAMLは「便利なJSON」として使われることが多い一方、その複雑性から落とし穴も多く、しばしば批判の対象になります。 なぜYAMLはそこまで複雑なのでしょうか? その背景のひとつは、本来のYAMLがJSONとは大きく異なる目的意識で作られているからです。 本稿ではYAML specに従う形でYAMLのコンセプトを解説することを目指します。残念ながら、ここに書かれているYAMLの思想は実際には実用されているとは言い難いですし、これらの背景を理解しても「YAMLは複雑だ」という事実がひっくり返ることはないでしょう。それでも、YAMLの複雑さの源泉を体系的に理解し、YAMLとほどほどの距離感で付き合う助けにはなるのではないかと思います。 この記事ではこういう話をしますYAMLはJSONとは独立に、異なる目的で生まれた野心的な仕様であるアンカーやタグなどの強力な構文は、これらの目的を満たすために
JSON Feed
We’ve updated the spec to version 1.1. It’s a minor update to JSON Feed, clarifying a few things in the spec and adding a couple new fields such as authors and language. For version 1.1, we’re starting to move to the more specific MIME type application/feed+json. Clients that parse HTML to discover feeds should prefer that MIME type, while still falling back to accepting application/json too. The
JSONとBigInt
ちょっと前にblueskyで見かけた話題。もとは「GraphQLのスキーマではintが32ビットしかなくて、64ビット整数とかないのがイケてない」といった話だったかなと思う。直感的にはこれは「Javascriptではすべてが倍精度浮動小数点数だから64bit intがないから」ということになるが、よくよく調べてみるといろいろややこしい歴史的事情があるようだ。 たしかにJSにはもともとひとつのNumber型しかなく、いわゆるdouble型(倍精度浮動小数点)だけで数値を表現してきた。IEEE754の倍精度浮動小数点数は仮数部が52ビットあるので、実際には32ビット整数ていどであれば全て誤差なく表現できる。なので32ビット整数または倍精度浮動小数点数がどちらも使えるというふうに理解されてきた。 そうはいっても不便なので、現代のJSにはBigIntがある。ES2020で導入されたらしい。ただし普
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSON schema for object with either A and B or C required properties