色々なプログラミング言語で JSON をパースするためのイカしたサービス quicktype - かずきのBlog@hatena
今日、マイクロソフト本社から来た David さんとお昼ご飯をしたときに教えてもらえた彼のプロダクトが凄かったので紹介したいと思います。 quicktype.io quicktype JSON をペーストするとシリアライズ・デシリアライズするためのコードを出力してくれるサービスです。 例えば、以下のような JSON があるとします。 { "name": "Kazuki Ota", "age": 36, "pets": [ { "name": "hoge" }, { "name": "foo" } ] } ページに張り付けるとこういうコードが生成されます。 // To parse this JSON data, add NuGet 'Newtonsoft.Json' then do: // // using Sample.Models; // // var data = Person.Fro
API Blueprint | API Blueprint
API Blueprint. A powerful high-level API description language for web APIs. API Blueprint is simple and accessible to everybody involved in the API lifecycle. Its syntax is concise yet expressive. With API Blueprint you can quickly design and prototype APIs to be created or document and test already deployed mission-critical APIs. Tutorial Tools section Focused on Collaboration API Blueprint is bu
Swagger+JSON SchemaでAPIの型をテストして開発サイクルをスピードアップさせた話 - pixiv inside
CTO兼福岡オフィス立ち上げ担当として新アプリを作っている@edvakfです。 JSON APIを開発しているとこういう問題がありがちですよね。 仕様どおりにAPIの形式を作ったはずだけどなんか自信が持てない テストでいくつかのキーが存在するかの簡単なチェックはしてるつもりだけど、全部チェックするのは大変すぎる APIのControllerやViewをリファクタリングしたらレスポンスの形が変わってアプリがめっちゃクラッシュし始めた というのが怖くて誰もリファクタリングできなくなった APIドキュメントがメンテされない 知らない間にレスポンスのフィールドが増えてたけどドキュメントに書いてない これらを解決したい！と思って試行錯誤したら、スマートに解決することができました。この記事ではRailsのことについて書きますが、考え方は他の言語・フレームワークでも同じです。 なお、今回使ったgemのバ
JSON Schema 中心設計 - FlowType から RAML まで - - Qiita
はじめに Web サービスの運用を続けていくと，依存関係が徐々に複雑になっていきます．そしてメンテナンスするものが増えた結果，それらが相互に乖離していく，といったことが起こりがちです． そこで今回は，JSON Schema のみをメンテナンスしていくことで，動的チェック (バリデーション)，静的チェック (FlowType)，API ドキュメント生成，スタブ作成といった様々な恩恵を享受し，品質と保守性を同時に向上させるアプローチについて書いていきます．この JSON Schema を中心に据えたエコシステムを，JSON Schema 中心設計と呼ぶことにします． JSON Schema の仕様については割愛しますので，必要な方は こちら をご覧下さい．また，本記事では JavaScript での事例を紹介しますが，他の言語でも同様の適用ができるかと思います． アプローチ 本記事では，以下の
GraphQLはWeb APIの次のフロンティアか？ | POSTD
RESTの規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが
JSONデータ圧縮方式をSnappyからzstdに切り替えた事例紹介 | BLOG - DeNA Engineering
JSONデータ圧縮方式をzstdに切り替えデータ量を38.3%削減した事例、及びマイクロサービスの無停止アップデート事例について紹介したいと思います。 はじめに JPRゲーム事業本部開発基盤部の池田周平です。先日 Rails5対応についてDeNA techブログに投稿 した@namusyakaと同じチームで働いています。 JSON文字列をRDBに格納する際の圧縮フォーマットをSnappyからzstdに切り替え、データ量を削減した事例を紹介したいと思います。本対応を実施した目的はDB負荷対策です。DBで扱うデータをより小さくすることで、DBサーバのDiskI/O負荷とMaster-Slave間のレプリケーション遅延対策を目的としています。 「Sakasho」は、DeNAが持つモバイルゲームのためのプラットフォームです。複数タイトルのゲームを取り扱っており、一部データはゲーム毎の仕様差を吸収し
続・目指すのはぶっちぎりの速さ! HTML5版 Cacoo で刷新されたデータアーキテクチャを紐解く | 株式会社ヌーラボ(Nulab inc.)
こんにちは。Cacooの平山です。現在、僕たち Cacoo チームは脱Flash・ HTML5 化に向けて最終の追い込みの真っ最中です。そんな中ではありますが、前回の「ぶっちぎり」記事では、HTML5化に向けた描画技術としてSVGを選択したことをお伝えしました。今回は、HTML5版のもうひとつの改善ポイント「データ面での刷新」を紹介したいと思います。 Cacoo のデータ形式や構造の刷新・JSONフォーマットへの移行 HTML5版では、描画にSVGを採用するという変更だけではなく、抜本的なデータ形式や構造の刷新も行いました。これには以下3点の理由があります。 Flash版ではAMFというFlashに特化したデータフォーマットを採用している 図に含まれるデータ量に応じて、パフォーマンスが低下しやすい構造である サーバー内でデータを処理しにくい 1点目はFlashから脱却するにあたり対応必須な
JOSE（JavaScriptオブジェクトへの署名と暗号化）は、絶対に避けるべき悪い標準規格である | POSTD
注： 本稿は元はJSON Web Tokens（JWT）について書いたものですが、JWTはJavascript Object Signing and Encryption（JOSE）のサブセットであるため、以下の批評はどちらかというとJOSE全体に焦点を当てています。 もし既にJavascript Object Signing and Encryption（JOSE）を実装することを決めているなら、それがJSON Web Tokens、JSON Web Encryption（JWE）、JSON Web Signatures（JWS）のいずれであっても、その決断に疑問を持つべきです。間違いを犯そうとしている可能性があります。 この投稿に書いたことはすべて、RFC 7519、RFC 7515、そしてRFC 7516に則っています。将来、新規のRFCでは以下に挙げるような欠陥はなくなっている可能
npmで成果物をsemantic-release :rocket:
npmで成果物をsemantic-release :rocket: 目的: npmで単独のJSONファイルを配布したい 例) 辞書ファイル、更新頻度が高いファイル 最終的にやりたいこと npm installして npm install technical-word-rules requireするだけで辞書ファイルをJavaScriptから使いたい var json = require("technical-word-rules"); // 辞書ファイルを使えるようにしたい 方法1: install hook npmのpacakage.jsonにはinstall時に行う挙動を書くことが出来る "scripts": { "install": "node install-hook.js" }, npm install technical-word-rulesするとinstall-hook.js
【Unity】Protocol Buffers と JSON のパフォーマンス速度を比較した話 - KAYAC engineers' blog
はじめに はめまして、カヤックのゲーム技研の Unity エンジニアのアフィフです。 カヤックで運用しているゲームタイトルでは、主に JSON フォーマットでデータを管理していましたが、最近ではゲームのデータ量がどんどん増えていく傾向にあり、データの読み込みがボトルネックになりつつあります。 JSON のデシリアライズは結構遅いので、もっと良いデータフォーマットがないかと探したところ、Protocol Buffers というデータフォーマットを見つけました。 今回は、プロジェクトに導入する前にパーフォマンスを検証した結果について書きます。 Protocol Buffersとは Protocol Buffers は Google により開発されているバイナリベースのデータフォーマットです。JSON 形式はテキストベースのデータフォーマットなので、オーバヘッドがあります。 例えば、この JSO
たぶんこれが一番分かりやすいと思います React + Redux のフロー図解 - Qiita
【追記】 もうこれ古いから参考にしないでください https://t.co/mXtcc73Orf — もし Laravel が流行しなくなってこられてきてたとしたら、絶対に捨てられてこられてたと思うか (@mpyw) January 26, 2021 Redux にはその昔 connect()() とかいうクソ API と， Redux-Saga とかいう宗教がありました という考古学です — もし Laravel が流行しなくなってこられてきてたとしたら、絶対に捨てられてこられてたと思うか (@mpyw) January 26, 2021 読者対象 Tutorial: Intro To React - React Example: Todo List · Redux 「チュートリアルそれぞれ一周した！Reactは何とか理解できたが，Reduxがさっぱりわかんねぇ！」 ぐらいの人向け。自分
Isomorphic JSで作られたWebサイトの脆弱性検査 | Recruit Tech Blog
サイバーセキュリティエンジニアリング部の西村です。 Recruit Engineers Advent Calendar 2016の12月6日の記事を担当します。 先日、あるWebサイトの脆弱性検査を業務で担当しました。対象のサイトは、Node.js + React + Reduxを用いてIsomorphic JSを実現しており、検査でもこのアーキテクチャに特有の脆弱性が見つかりました。 この記事では、検査で発見した脆弱性をもとに、Isomorphic JSのWebサイトを構築する際に気をつけるべきポイントを紹介します。 Isomorphic JSとは Isomorphic JSは、近年、注目されているWebのパラダイムで、サーバとクライアントで同一のJSのソースコードを利用することが特徴です。これにより、サーバとクライアントの双方でHTMLを生成できるようになり、従来のSPAに見られたSE
JavaScript で クラスベースの設計より関数指向の実装を薦める理由 + GraphQL について - mizchi's blog
最初に: 「Functional Programming 最高！」という話ではないです JSは通信やストレージに保存するデータの扱いの関係で、JSONにシリアライズできることが至上命題になるケースが多いので、クラスベースの設計で自身に副作用を起こすメソッドより、イミュータブルな T => T なstatic methodとして切り離しておくと扱いやすいケースが多い— 現場の声 (@mizchi) 2016年9月6日 複雑なオブジェクトのシリアライズは簡単だけど、逆にシリアライズされたオブジェクトからビルダを構築するのが難しいので、JSONの構造体自身とは別に独立して独立したメソッドとしてビルダが切り離されている方が扱いやすい— 現場の声 (@mizchi) 2016年9月6日 一応コンストラクタ名を保存してシリアライズ/復元する方法はあって、RPGツクールMVのコードを読むとそういう感じに
npm shrinkwrapで依存モジュールのバージョンを固定 - Qiita
Node.jsで作られたアプリケーションをデプロイするときに、npm shrinkwrapを使って依存モジュールのバージョンまで固定した状態でインストールする方法を紹介します。 背景 npm install で依存モジュールをインストールするとき、package.json で ^1.2.3 や ~1.2.3 といったバージョン指定をしているモジュールが1つでもあると、semver に従って 1.2.5 などのより新しいバージョンがインストールされる可能性があります。 セマンティックバージョンの意味からすれば、1.2.3 が互換性のある 1.2.5 に置き換わっても同じように動作すべきですが、現実問題としてテストしたバージョンと本番にデプロイされるバージョンが意図せず変わってしまうのは気持ちが悪く、依存モジュールを含めてバージョンを固定する方法を調べました。 実現方法 まずは npm ins
Chrome Web Store Publish APIを使ってみようよ - Qiita
Chrome Web Storeに拡張機能等を公開する場合, manifest.jsonやら一式をzipで固めてフォームからアップロードして公開する必要があります. この作業, 適当なシェルスクリプトを書いておけば済むんですけどもどうにも億劫で, デプロイする度に"うまいこと自動で出来たらいいのになー"と思ってたんですが, 最近調べたら公開作業とか自動で出来そうなAPIがありました. Using the Chrome Web Store Publish API - Google Chrome 軽くみたところChrome Web Store向けのzipのアップロードや公開用のAPIが用意されているようです. これはもう試すしかないっしょということで, さっそくコードを書いて動かしてみます. コードの部分はPythonで書いていくよ. 準備はGoogle Developer Consoleから
Tweet2VecでQiitaの投稿を形態素解析せずに分類する - Qiita
目次 やりたかったこと Qiita投稿を取得する Tweet2Vecを使う GPUインスタンスを使う タグ予測結果 類似投稿を出してみる 考察と課題 やりたかったこと 短い日本語文書（ツイートなど）を分類したい ニューラルネットワーク使いたい 形態素解析せずにやりたい SNSの投稿などを処理する場合、誤字、脱字、スラング、新語、絵文字、顔文字、外国語、専門用語、表記ゆれなどが多く含まれるため、形態素解析器を用いたアプローチは不利に思われる。近年のNLP論文を読んでいると単語レベルではなく文字レベルで学習させる方向にいっているようなので、その流れに乗ってみる。日本語は一文字あたりの情報量が大きいので英語より有利だと思う。 文書が長すぎず、形態素解析しにくそうで、ある程度トピックにまとまりがある題材として、Qiitaの投稿をタイトルのみで分類してみることにした。Qiitaの本文はmarkdow
自分が依存しまくってるnpmパッケージを表示するツールつくった - マルシテイア
https://www.npmjs.com/package/what-do-i-depend-on github.com 先日のleft-pad騒動で、自分のプロジェクトのnode_modulesを慌ててチェックした。 普段依存の依存とかまったく意識してないけど、いざ見なおしてみるとその数の多さにビックリする。 全ての依存を把握するのは正直無理だけど、ざっと見てみるだけでも発見がある。 意外とscoped packageが使われてたり。めちゃくちゃミニマルなパッケージが人気だったり。 babel関係のパッケージが多すぎて目眩がしたり。 というわけで、自分のプロジェクトの依存パッケージを再帰的に調べて、依存度合いをチェックするツールを作った。 node_modules/ 内の package.json を再帰的に調べて、パッケージが登場した回数を表示する。 使い方 インストール npm i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ちょっと時間かかるけど Amazon SES でのメール送信エラーをなるべく検出する方法 - Qiita
GitHub - amireh/happypack: Happiness in the form of faster webpack build times.
JSONを使ってSassとJavaScriptで設定値を共有する方法
