JSONとBigInt
ちょっと前にblueskyで見かけた話題。もとは「GraphQLのスキーマではintが32ビットしかなくて、64ビット整数とかないのがイケてない」といった話だったかなと思う。直感的にはこれは「Javascriptではすべてが倍精度浮動小数点数だから64bit intがないから」ということになるが、よくよく調べてみるといろいろややこしい歴史的事情があるようだ。 たしかにJSにはもともとひとつのNumber型しかなく、いわゆるdouble型(倍精度浮動小数点)だけで数値を表現してきた。IEEE754の倍精度浮動小数点数は仮数部が52ビットあるので、実際には32ビット整数ていどであれば全て誤差なく表現できる。なので32ビット整数または倍精度浮動小数点数がどちらも使えるというふうに理解されてきた。 そうはいっても不便なので、現代のJSにはBigIntがある。ES2020で導入されたらしい。ただし普
Google for Jobs対応 求人情報構造化データ JobPostingおさらい
Blog Google for Jobs対応 求人情報構造化データ JobPostingおさらい 2019.01.19 2018.12.30 2019年1月、日本においてもGoogleの検索で仕事や転職に関連したキーワードを入れると、広告と一般の検索結果の間(エンリッチ)に求人情報を表示するGoogle for Jobs(グーグル・フォー・ジョブズ)のサービスがローンチされます。本記事では、求人情報がGoogle for Jobs に掲載できるようになる求人構造化データ(JobPosting)について解説していきます。 Google for Jobsは17年6月にアメリカでリリースされたGoogleの求人情報サービス。アメリカを皮切りに世界100カ国近くの国で、中小企業が運営するWebサイトから、何千何万ものリストが掲載されている求人サイトまでWeb上の膨大な求人情報がまとめられている。
ProtocolBuffersでprimitiveのデフォルト値と値が入っていないことを区別したいときにどう書くか - だいたいよくわからないブログ
結論 wrappers.protoが便利 背景 protobufでは値を省略したときに、その型で定められたデフォルト値が代入されます。 例えばstringを省略すると自動的に""を指定したことになり、「値が指定されなかった」のか「空文字列を明示的に入れた」のかを区別しないように書くことが求められます。 この仕様は便利なのですが、時には区別したいケースもあります。 このとき下の方式2, 3のようなテクニックを用いて未指定とデフォルト値を区別することができます。 message Example { // 1. ダイレクトに定義(デフォルト値と未指定を区別できない) string foo = 1; // 2. 専用のmessageを定義 message Bar { string value = 1; } Bar bar = 2; // 3. oneofで定義 oneof baz_option {
事実上最後のJSON仕様「RFC 8259」と「ECMA-404 2nd Editon」公開。UTF-8エンコード必須に
RESTful APIのデータフォーマットなどで広く使われているJSON。IETFはJSON仕様「RFC 8259」を発表。従来の仕様をブラッシュアップしつつECMAの仕様との統一も実現した、事実上最後のJSON仕様になると見られる。 IETFからJSON（ジェイソン）の仕様を示した「RFC 8259」（The JavaScript Object Notation (JSON) Data Interchange Format）が公開されました。 IETFにおけるJSON仕様は、これまで「RFC 7159」が参照されていましたが、RFC 8259の公開によりRFC 7159は廃止（Obsolete）となりました。 RFC 8259は、多数の実装と十分な運用実績を積み重ねたインターネット標準「STD 90」としても参照されます。 ECMAとの統一を実現。事実上最後のJSON仕様になると見られる
アノテーションからドキュメントを作れるswaggerの使い方 - gong023の日記
swagger の概要と、基本的な使い方をサンプルを交えて書く。 なお、終始 PHP なので気をつけて下さい。 swagger の概要 開発ドキュメントをどうやって書くかという話題は常々ある。そして一番素直なアプローチを取ると、大抵 wiki みたいなアプリケーションを用意して、そこにドキュメント書こうぜという話になる。しかし、この管理は割とすぐ破綻してしまう。 理由はいろいろあるが、最新のコードに追従できなくなるとか、統一されたフォーマットを保証できず書き手によっては何を書いているのか全くわからないとかそういうケースが多い。 前者について、 swagger はアノテーションでドキュメントを書けるので違いは起きづらくなる。（ それでも不足だが自分でライブラリ作って補った ） また後者に関していえば、swagger は API の仕様を記述するためのフォーマットを提供してくれる。 つまり、s
curl コマンドで、特定の(ヘッダ)情報だけを取り出す。レスポンスヘッダ write-out (-w ) - それマグで！
curl は色々とオプションがあるので、使い込むと楽しい -w オプションで、必要な物を取り出す。 レスポンスコード curl -I -s -o /dev/null http://store.apple.com -w '%{http_code}\n' 301 ダウンロード・サイズ curl -L -s -o /dev/null http://store.apple.com -w '%{size_download}\n' 59770 これらを必要な出力（JSON)にまとめる 出力はJSONにまとめることが出来る takuya@atom:~$ curl -L -s -o /dev/null http://store.apple.com -w '{ "dl_size" : %{size_download}, "status_code" : %{http_code} }' | jq . { "dl
JSON API — A specification for building APIs in JSON
If you’ve ever argued with your team about the way your JSON responses should be formatted, JSON:API can help you stop the bikeshedding and focus on what matters: your application. By following shared conventions, you can increase productivity, take advantage of generalized tooling and best practices. Clients built around JSON:API are able to take advantage of its features around efficiently cachi
PHPのJSONのエスケープ
(Last Updated On: 2023年12月8日) 追記：最近のOWASPガイドの更新でJavaScript文字列はUnicodeエンコードで安全性を確保するよう変更されました。元々このブログでもUnicodeエスケープのまま利用するように書いています。他の言語のユーザーはUnicodeエスケープを利用しましょう。PHPもASCII領域の文字をUnicodeエスケープするようにした方が良いと思います。これは提案して実現するように努力します。 JSONはJavaScriptのオブジェクトや配列を表現する方式でRFC 4627で定義されています。メディアタイプはapplication/json、ファイル拡張子はjsonと定義されています。 PHPにJSON形式のデータに変換するjson_encode関数とjson_decode関数をサポートしています。 JSON関数がサポートされている
全てが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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSON