はじめに 今やあらゆるアプリケーションは Go で書かれていると言っても過言ではない（過言）。そして、今やあらゆるデータは json であると言っても過言ではない（過言）。 となると、Go で json を扱う頻度も必然的に多くなる。そして初めて Go で json をデコードするコードを書こうとした人は、必ずこの問題にぶち当たる。 「json.Unmarshal と json.Decoder は何が違うのか？そしてどちらを使えばいいのか？」 そしてググると大抵以下のような答えにたどり着く。 入力が文字列（string）やバイト列（[]byte）の場合は json.Unmarshal() を使う 入力がストリーム（io.Reader）の場合は json.Decoder を使う なるほど、確かにパッと見はそれでいいように思える。思えるんだが、よく見ると実は他にもいくつか考慮すべき点がある。
![[Go] json.Unmarshal と json.Decoder の使い分け ～ json.Decoder に親しむ](https://cdn-ak-scissors.b.st-hatena.com/image/square/8b53126231c805e6489affeea33cbb9b9506f9dd/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--GE8Zjrfw--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BGo%25255D%252520json.Unmarshal%252520%2525E3%252581%2525A8%252520json.Decoder%252520%2525E3%252581%2525AE%2525E4%2525BD%2525BF%2525E3%252581%252584%2525E5%252588%252586%2525E3%252581%252591%252520%2525EF%2525BD%25259E%252520json.Decoder%252520%2525E3%252581%2525AB%2525E8%2525A6%2525AA%2525E3%252581%252597%2525E3%252582%252580%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3A%2525E3%252581%25258B%2525E3%252582%25258A%2525E3%252582%252584%2525E3%252581%2525BF%2525E3%252581%2525A4%2525E3%252582%25258B%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly96ZW5uLWRldi5naXRodWIuaW8vZGVmYXVsdC1hdmF0YXJzL2Rhcmsvay5wbmc%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
はじめに こんにちは。Sugawara Yuutaです。"Go言語で最速のJSONデコーダーを作った話", "それでも僕はGoで最速のJSONデコーダーを作りたかった"...以来の方はまた読んでいただきありがとうございます。まだの方は、経緯を伝えやすくなると思うので、そちらの方も読んでいただけたら幸いです。 その後 Go言語チームのメンバーが取り組んでいる新しいバージョンのJSONライブラリであるgo-json-experiment/jsonというレポジトリを発見しました。(厳密に言うと、知ってはいたのですが中身等は見ていない状態でした。) そこで学んだことが少しでも役に立てばとissueを提出したところ、そのときのJSONデコーダーに足りないものが見えてきたため、今回は僕の見つけた課題と、どのように解決しようとしたか・したかを話せればと思います。 見つけた課題 パフォーマンスも重要ですが
野良 HTTP JSON API クライアントを作ってると、API が返してくる JSON の形に確信が持てないし、「これ何に使うんだろ」みたいなフィールドもあったりして struct にエンコードするのをサボったりする。 そういったコードがライブラリとして使われる余地を残すとすると、struct で表現されていないデータにも何らかの方法でアクセスできるようにしておきたい。こういうパターンあるんじゃないかと思うが、みんなどうやってるのか分からなかったのでメモ。 まあ素直に、json.RawMessage を struct に持たせておくのが一番よいだろう。冗長にはなるが、構造体の定義されたフィールドに便利なデータはあるし、より詳細に見たいなら RawMessage 経由で生データを見ればよい。ということにする。また、RawMessage を保持している場合は JSON 化したときにこれをそ
動的型付けプログラミング言語や、class を持つようなプログラミング言語を使う場合、そのフィールドメンバの定義順などを意識する事は少ないかもしれません。 Go は struct という、C言語が持っている構造体と同じ様にメモリ配置され、構造体そのものをレシーバとして、メソッドを定義しつつプログラミングを行います。struct はデータ構造そのものを示し、それが大きくなるにつれ、当然ながらメモリ使用量も多くなります。 さて、例えば以下のコードを実行すると、struct 100 個分のサイズは幾らになるでしょうか。 package main import ( "fmt" "unsafe" ) type Account struct { TimeZone struct { Name string `json:"name"` UtcOffset int `json:"utc_
前回のエントリー、一周回って、人間が読み書きする設定ファイルはJSONが良いと思ったの続きです。 設定ファイルをどうするか問題はいろいろ悩ましい問題であります。そんな中、設定ファイル用言語という触れ込みのCUEがリリースされました。 すでに、NSSOLの方が、Linterとして使うという紹介記事をすでに書かれています。これはユースケースの一部（これでも有用ですが）です。まだ使い込んだわけではなく、チュートリアルとドキュメントを一通り読みつつ軽く試した程度ですが、全体的な紹介をしようと思います。 yamlやJsonのチェック(Lint)ができるCUEの紹介 CUEによってできるようになること主な特徴としては次のような感じです。 人が書く設定ファイル(JSON/YAML/TOML/iniあたりがライバル)のための言語 スキーマ定義が書けて、バリデーションが可能 テンプレート機能で一部が違うデー
↓↓↓こちらに移行しました↓↓↓ Goのhttp.Headerについて
I think I just made go-github 4x faster in 4 lines of code (and 4hrs). Always make sure you are reusing connections! https://t.co/ORCv1a4prv — Filippo Valsorda (@FiloSottile) March 27, 2016 go-github という、Google が開発している GitHub API ライブラリがあるのですが、今回 filosottile さんがたった4行のコードで実行速度を4倍にするという pull-request を書きました。 いったいどういう事かというと、golang の json.Decoder を使って http.Response.Body から JSON を読み取ると最後の改行(EOF)が読み込まれずに残
{ "period": "yy", "exec_period": { "start": { "month": 1, "week": 2, "day": 3, "hour": 4, "minute": 5 }, "end": { "month": 6, "week": 7, "day": 8, "hour": 9, "minute": 10 } }, "backup": [ { "local_dir": "directoryLo1", "server_dir": "directoryLo2", "server_host": "domaineName" }, { "local_dir": "directoryLo1", "server_dir": "directorySe2", "server_host": "domaineName" } ], "incremental_save": "1Y2
August 13, 2014 - golang TL;DR goの構造体につけるタグは、フォーマットが不正だと読み込まれない(当然) json.Marshalは、構造体のjsonタグがあればその値をキーとしてJSON文字列を生成する json.Unmarshalは、構造体のjsonタグがあればその値を対応するフィールドにマッピングする jsonタグがなければ、完全一致もしくはcase-insensitiveなフィールドにマッピングする では、ひとつづつ確認していきます。 goの構造体につけるタグは、フォーマットが不正だと読み込まれない(当然) goの構造体にはタグの機能があって、型の後に特定のフォーマットでアノテーションが記述できます type MyType struct { Hoge string `foo:"1" bar:"2"` } key:"value"をスペース区切りで複数かけ
grpc-gateway という gRPC からJSON APIへの変換プロキシ生成機を書いた。 これを使えばシステム内部ののmicroservicesはgRPCで通信しつつ公開APIはJSON APIで提供する、みたいなことが簡単になる。 なお、gRPCそのものについては mattnさんの記事 が参考になる。 背景 gRPCの良い点はいくつもある。 データはデフォルトでprotocol buffersで直列化される。ベストではないにせよ十分にコンパクト且つ高速だし、サイズで言えばJSONとは比べるべくもない。 簡単に複数の言語でサーバーのテンプレートやクライアントを生成できる。通信の詳細はgRPCにまかせて開発者はサーバーロジックの実装に注力できる。 design by Googleという安心感。 gRPCの素晴らしさは認めるものの、一方では欠点もある。まず、クライアントライブラリの多く
はじめに Go 1.4 にて導入されたgo generateコマンドを使って、JSONファイルからソースコードを自動生成してみます。 今回は、JSONファイルに定義されたWebアプリケーションのルーティング情報をもとに、ルーターのプログラムが記載された単純なソースコードを生成してみます。 今回の手順で作成したソースコードは、こちらのリポジトリに格納しています。 今回、ルーターにはgorilla/muxを使用しています。 JSONファイルからソースコードを生成するコマンドの作成 まずは、以下のようなルーティング情報が記載されているJSONファイルを読み込み、ルーターのプログラムが記載されたソースコードを生成するコマンドを作成します。 [ {"method": "GET", "path": "/", "handler": "topHandler"}, {"method": "GET", "pa
このエントリは Go Advent Calendar 2014 の記事です。 さて、僕はJSONSchemaで疲弊してたんですが、主に疲弊してた理由としてはJSONの表現力不足(ケツカンマ許さない、コメントかけない等)とJSONSchema Validatorで不正な値があった時の情報量の少なさでして、JSONの表現力不足に関しては皆さんYAML使ったりして色々解決してるとは思います。 そこで自分もYAMLではなく、JSON5使って解決しようと考えてgolangで実装してみました。 JSON5の詳細に関してはこちらのエントリを参考にされると良いかと思います。 普通にjson5をインストールする インストールは簡単。 $ brew tap yosuke-furukawa/json5 $ brew install json5そんで、こんな感じのjson5ファイルを用意して、 // This i
３行で言うと herokuが作ってる prmd を使って、JSON SchemaからAPIドキュメントを出力したよ！ スキーマ定義から、GoのAPI実装コードも出力するツールを作ったらめっちゃ捗るよ！ Goのバリデーション用のライブラリも作ったよ！ 今回作ったものの概要とサンプルコード 概要 以前から、APIを開発する上で、以下のようなことが課題となっていました。 そもそもドキュメント書くのがつらい それもあって、ドキュメントより先にコードが変わってしまう ドキュメントと実装の状況の違いが把握しづらい また、ロジックがそんなに複雑ではないAPIでは、実装の作業は リクエストデータのバリデーション 出力データの整形 (フィルタリング) の２つの作業が大きな割合を占めます。 APIの定義ファイルからドキュメントと、バリデーションや出力データ整形のコードを自動生成できれば、大幅に効率が上がると思
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
