EventQL - The database for large-scale event analytics
What is an Online Community Software and How Does It Work - EventQL EventQL is a distributed, column-oriented database built for large-scale event collection and analytics. It runs super-fast SQL and MapReduce queries. The community software … the ideal channel for companies and organizations looking for additional interactions with their community? The first AC Repair appeared in the Best AC Repa
go generateを使って、JSONファイルからソースコードを自動生成する
はじめに Go 1.4 にて導入されたgo generateコマンドを使って、JSONファイルからソースコードを自動生成してみます。 今回は、JSONファイルに定義されたWebアプリケーションのルーティング情報をもとに、ルーターのプログラムが記載された単純なソースコードを生成してみます。 今回の手順で作成したソースコードは、こちらのリポジトリに格納しています。 今回、ルーターにはgorilla/muxを使用しています。 JSONファイルからソースコードを生成するコマンドの作成 まずは、以下のようなルーティング情報が記載されているJSONファイルを読み込み、ルーターのプログラムが記載されたソースコードを生成するコマンドを作成します。 [ {"method": "GET", "path": "/", "handler": "topHandler"}, {"method": "GET", "pa
HaskellでJSON Web APIを作ると幸せになれるかもよ - Fujimura
先日Yesod勉強会第2回でHaskellでJSON Web APIを作る話しをしました。 内容的には下記のような感じです。 Web開発はクライアントサイドの技術が発達して、Web APIを作る機会が多くなった最近のフロントエンドは難しいし、分業したほうがいいっぽいYesodは独自技術＆フルスタックすぎて分業辛いではscotty + persistent + aesonでJSON Web API作ろうぞなんか想像以上の相性の良さ。幸せになれそうなイキフンがビシビシ来てる発表資料はこちら。 ちなみにscottyはsinatraみたいな奴、aesonはJSONライブラリ、persistentはORマッパーです。 何しろaeson + persistentの相性がバッチリでした。発表後に@thimuraさんが見つけた じつは persistent のスキーマ定義で、テーブル名の横に js
JSON Hyper-Schemaのようなサービスディスクリプションがうまくいかない理由 - ぶろぐ。@はてな
RubyKaigiの発表のために考えていたのですが、発表本編に詳しく入れられなくなりそうなので、まとまりないですがブログに書いてみます。 SOAPでいうWSDL(Web Service Definition Language)のような、サービスのインタフェースを定義・記述するためのしくみを総称してIDL(Interface Description Language)と呼びます。 JSON Hyper-Schema*1もIDL、サービスディスクリプションの一種といえます。 WebのIDLは今までにもたくさん出てきて、しかしうまくいっていません。 なぜでしょう？ @yohei さん曰く、 RESTは統一インタフェースなんだから、そこにさらにインタフェースを定義するのはおかしい （API Meetup #1 質疑応答より） WebAPIのこれまでとこれから from yohei これはどういうこ
JSON Hyper-Schema からAPIドキュメントとGoのコードを自動生成する | The Wacul Blog
３行で言うと herokuが作ってる prmd を使って、JSON SchemaからAPIドキュメントを出力したよ！ スキーマ定義から、GoのAPI実装コードも出力するツールを作ったらめっちゃ捗るよ！ Goのバリデーション用のライブラリも作ったよ！ 今回作ったものの概要とサンプルコード 概要 以前から、APIを開発する上で、以下のようなことが課題となっていました。 そもそもドキュメント書くのがつらい それもあって、ドキュメントより先にコードが変わってしまう ドキュメントと実装の状況の違いが把握しづらい また、ロジックがそんなに複雑ではないAPIでは、実装の作業は リクエストデータのバリデーション 出力データの整形 (フィルタリング) の２つの作業が大きな割合を占めます。 APIの定義ファイルからドキュメントと、バリデーションや出力データ整形のコードを自動生成できれば、大幅に効率が上がると思
CBOR — Concise Binary Object Representation | Overview
RFC 8949 Concise Binary Object Representation “The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.” JSON data model CBOR is based on the wildly successful JSON data model: numbers, strings, arrays, maps (called objects in JSON)
RESTとJSON、スキーマ定義について思うところ
mozaic.fm #7 RESTや#mozaicfm REST を聴いての感想、それから「Web+DB vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。 REST設計について WebAPIを設計するうえでRESTが重要であることは周知のとおりである。 “Constraints are liberating”「制約は自由をもたらす」 @t_wadaさんがおっしゃっているように、RESTを前提にすれば、「アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる」という大きなメリットが生まれる。 しかし、相変わらずリソース設計やらインターフェース設計やらで悩んでおられる方も多いと聞く。 その一方で個人的には適切なフレームワークを使えばREST設計で悩まなくてもよいはず(※3)という思いもある。 インターフェース設計な
Goのjson.Marshal/Unmarshalの仕様を整理してみる · I Will Survive
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"をスペース区切りで複数かけ
Big Sky :: clib の使い勝手にマジ感動した
C言語でアプリケーションを書くのは他の言語と比べて少し気合が必要ですよね。例えば HTTPからデータを取得する 取得したデータを json パースする 結果の一部を色付きで表示する こんな場合、C言語プログラマは 「HTTP か、じゃぁcurlかな」 「JSON か、parson かな」 「色表示か...エスケープシーケンスでもいいけどWindowsがなー...」 といった事を考え、そこから curl や parson といった資材の調達を始める事になります。途中で新しい機能を追加したくなり、それを外部ライブラリに頼る場合だとその都度資材を調達する必要があり、思考を停止しなければなりません。 この辺は ruby や perl、nodejs、golang 等の様に、ちょっとした手間だけで済ませたい物です。 またC言語の場合、ヘッダファイルはシステムの include フォルダに提供元が期待す
全てがJSONになる - ✘╹◡╹✘
TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIはレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or
JSON-RPC 2.0 の over HTTP についての雑感 - tokuhirom's blog
「うちは JSON-RPC やらんのかね」みたいなことを聞かれたので、前に考えた内容をここに晒す。 method 名について メソッド名が content-body にしか入らないので、ログがおいづらい。 (多分、実際に運用するにあたってはクライアント側で ?method=XXX みたいに付与するとかやって運用するんですかね? なんかちょっと本末転倒っぽい) 特定の API method だけこっちのサーバーにふる、とかするのがつらそう。 id が意味ない over HTTP で運用する場合、id を付与していることのメリットがない。 デメリットとして、JSON 自体をまるっとキャッシュすることができなくなる。 メリットについて フォーマットがきまっているので、server2server とか、小規模のサービスとか、あるいは over TCP でやるんなら便利なケースはあるかな、とおもって
Fat JSON
Most server-side APIs these days are JSON-over-HTTP. Developers are generally comfy with this, but I notice when I look at the JSON that it’s often, uh, what’s the tactful term these days? Let’s say “generously proportioned”. And I see clumsy code being written to walk through it. The options for dealing with this are interesting. For example · I’ve been working with keybase.io recently; when you
ffjson: faster JSON serialization for Golang | Paul Querna
ffjson is a project I have been hacking on for making JSON serialization faster in the Go programing language. ffjson works by generating static code for Go’s JSON serialization interfaces. Fast binary serialization frameworks like Cap’n Proto or Protobufs also use this approach of generating code. Because ffjson is serializing to JSON, it will never be as fast as some of these other tools, but it
JSON5 – JSON for Humans
JSON for Humans View the Project on GitHub json5/json5 JSON5 – JSON for Humans JSON5 is an extension to the popular JSON file format that aims to be easier to write and maintain by hand (e.g. for config files). It is not intended to be used for machine-to-machine communication. (Keep using JSON or other file formats for that. 🙂) JSON5 was started in 2012, and as of 2022, now gets >65M downloads/w
サーバサイドからクライアントサイドのJavaScriptを呼び出す際のベストプラクティス - kazuhoのメモ置き場
JavaScript文字列のエスケープ – yohgaki's blog に対して、 最近だと id="hoge" data-foo="<% bar %>" しておいて $("#hoge").data('foo') でとりだすのが主流かと思います。 はてなブックマーク - JavaScript文字列のエスケープ – yohgaki's blog のように、 そもそもJavaScriptコードを動的生成すべきでない JavaScriptコードに渡す変数はHTMLノードを経由すべきだ というような反論がついています。 が、はたしてそうでしょうか。 僕には、元の記事の手法も、HTMLノードを経由する手法もあまり好ましくない*1ように思えます。 そもそも、HTML生成時にXSS脆弱性が発生しがちなのは、 タグや静的な文字列と動的に生成される文字列が混在し 埋め込まれる多数の文字列を正しくエスケープ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC 準拠的な JSON 形式について - Qiita
DeNA Engineering - DeNAエンジニアのポータルサイト
Backend made Easy
GitHub - bevry/cson: CoffeeScript-Object-Notation. Same as JSON but for CoffeeScript objects.
【Rails 高速化】ペパボのフリマアプリ「kiteco（キテコ）」の API を高速化したときのことを詳しく書いてみた - 彼女からは、おいちゃんと呼ばれています
