GitHub - flerro/jop: A cli JSON processorYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Swiftで面倒なJSONの取り扱いをさらに10倍便利にするclass JSON - Qiita
Swiftで面倒なJSONの取り扱いを10倍便利にするSwiftyJSONをもってしても、まだJavaScriptよりも面倒だったのが悔しかったので書きました。 https://github.com/dankogai/swift-json/ Synopsis AnyObjectなSwiftオブジェクトも、こうして JSON Stringにできます。 let obj:[String:AnyObject] = [ "array": [JSON.null, false, 0, "",[],[:]], "object":[ "null": JSON.null, "bool": true, "int": 42, "double": 3.141592653589793, "string": "a α\t弾\n?", "array": [], "object": [:] ], "url":"http:/
拡張JSON SQL Injection(?)についての補足 - TechTalkManiacs
JSON SQL Injection、PHPならJSONなしでもできるよ | 徳丸浩の日記 この記事で説明されているJSON SQL Injectionと同様の動作が非JSONのリクエストでも発生する問題ですが、正しくはjQueryによるAjaxリクエストとサーバーサイドにPHP、Ruby on Railsの組み合わせでも発生します。 jQueryはパラメーターのシリアライズにおいて、PHPやRuby on Railsと同じようにブラケットによる多次元ハッシュのシリアライズ方法を採用しています。 Ruby移植版も含めて対策は進んでいますが、リクエストヘッダーのHTTP_X_REQUESTED_WITHでアクセスをAjaxにのみ限定する方法は対策とはならないので注意が必要です。
Swiftで面倒なJSONの取り扱いを10倍便利にするSwiftyJSON - Qiita
SwiftyJSON https://github.com/lingoer/SwiftyJSON 上記を読んでしまえば一瞬なんですが、一応使い方をこちらにもそのまま書いておきます。 JSONの取り扱いって面倒ですよね？ [ { ...... "text": "just another test", ...... "user": { "name": "OAuth Dancer", "favourites_count": 7, "entities": { "url": { "urls": [ { "expanded_url": null, "url": "http://bit.ly/oauth-dancer", "indices": [ 0, 26 ], "display_url": null } ] } ...... }, "in_reply_to_screen_name": null, }
Dan's Stuff: Your Premier Blog for Car Auctions
Dive into the Exciting World of Car Auctions At Dan’s Stuff, we bring you the thrill and excitement of car auctions right to your screen. Our blog is dedicated to helping you navigate the fast-paced world of car auctions with confidence and expertise. What You’ll Find Here Expert Advice: Learn the ins and outs of car auctions from seasoned professionals. Our tips and tricks will help you make info
ユーザ由来の構造化データによるSQLインジェクション | tech - 氾濫原
Kazuho's Weblog: The JSON SQL Injection Vulnerability について。元記事をはっちゃめっちゃに要約すると SQL::Maker にユーザから受けとったデコード済み JSON をそのまま突っ込むと SQL インジェクションになる場合がある SQL::Maker 側でそういったことが起こらないように strict オプションをつけたから、できればそっち使え 別に SQL::Maker に限らないから気をつけろ という話っぽい。本来であればユーザ入力をタイプチェックをすべきだけど、クエリビルダレベルでも、脆弱性にならないようにもうちょっと考慮してもいいよねという趣旨かな… strict モードは非互換なので、既存のコードが動かなくなる可能性があるようです。 Teng での対応 Teng を使っているとデフォルトで SQL::Maker がクエリビ
SwiftでWebAPIアプリを作った時の要点 - Qiita
func reload() { // Thanks to tiqav api! ( http://dev.tiqav.com/ ) let URL = NSURL(string: "http://api.tiqav.com/search/random.json") let req = NSURLRequest(URL: URL) let connection: NSURLConnection = NSURLConnection(request: req, delegate: self, startImmediately: false) // NSURLConnectionを使ってアクセス NSURLConnection.sendAsynchronousRequest(Req, queue: NSOperationQueue.mainQueue(), completionHandler: s
uu59のメモ | RailsとJS(vue.js)の連携
前書き Railsを使いつつJSもそこそこ書きたい、という条件であればまず前提としてjQuery脳を捨てましょう。jQueryスタイルで考えるかぎり何をどうやっても破綻するのでJSを諦めるか保守性を諦めるかして覚悟を決めましょう。 捨てるのは「jQuery」ではなく「jQuery脳」です。jQueryでグローバルな領域に進出してメソッドチェインで狼藉を働いたり、いま現在目の前にあるHTMLだけを考えてDOM操作をしたり、$.onと$.triggerを使ったクロージャ内部へのGOTOなどを記憶から消しましょう。 可能な限りスコープを小さく保つのはプログラミングの基本原則といえます。その原則を思い出し、JSを軽く扱わず、一般的なプログラミングと同様に閉じられた関心事にのみ注力するようにしましょう。 RailsとJSと役割分担 Railsもviewとしてテンプレートエンジンの処理を持っていますが
golang で JSONPath 的にデータ取り出したいときは @mattn_jp の go-scan が便利 - tokuhirom's blog
golang で net/http とってきて JSON を parse して所定のキーを取り出すプログラムを書きたかった｡ こういう場合､JSONPath とか使って書きたいのだが､JSONPath が完全にサポートされている go のライブラリは見当たらなくて､mattn_jp さんが JSONPath 書こうとして途中でやめた gist がひっかかってくる程度｡あとなんか yasuyuky/jsonpath というのもあるのだが､これはいわゆる JSONPath ではない｡ JSONPath なくてマジ不便ヤンケ､と思っていたが､mattn_jp さんが go-scan というライブラリを書いていた｡ golangのjson、型を作るかmap[string]interface{}にしてキャストするしかなくて最初はgolang面倒臭いなって思ってたけど小規模なら後者で十分だしそれ以上の
全てが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
jsプロジェクトのメタファイルが多すぎてウザいのでchestというのを使ってみたメモ - DRYな備忘録
メタファイルが多すぎる TypeScriptに限った話ではないのだけれど、JavaScript関連のプロジェクトつくってるとパッケージ管理などを定義するメタファイルがトップディレクトリに散乱することになる。たとえば otiai10/prisc at freeze/before-chest · GitHub ここの bower.json Gruntfile.coffee testem.json あたりがそれ chestというのがあるっぽい watilde/chest · GitHub The easy metafile manager とのこと インストール % npm install -g chest % which chest /Users/otiai10/.nvm/v0.11.9/bin/chest つかってみる % chest put bower.json [?] Add bower
通信プロトコルから見る艦隊これくしょん on 第十回 カーネル／VM探検隊
3. レスポンスが悪い理由 • 通信プロトコル(REST API)に無駄が多かった • リクエスト数が無駄に多い • レスポンスのJSONが無駄に大きい • JSONのデコードが遅かった • as3corelibのJSONデコーダーが使われていた（たぶん） • ActionScriptで書かれていて遅い 2014/5/25 第十回 カーネル／VM探検隊 3 4. 4月23日に全面改良 • 春イベント「索敵機、発艦始め！」の開始日 • イベント期間中はDAUが大きく増える • 過去のイベントでは通信エラーが頻発 • イベントに合わせて大幅改良 • 通信プロトコルの改良 • クライアントの改良 • Flash 11のネイティブJSONデコーダーを使用（たぶん） 2014/5/25 第十回 カーネル／VM探検隊 4 7. ログイン（旧） • スタート画面から母港ま で17リクエスト • マスター
RPJSONMapperでお手軽マッピング - Qiita
JSONから生成したNSDictionaryをオブジェクトにマッピングするのって面倒ですよね。 こんなん。 NSDictionary *jsonDictionary = @{ @"id": @123, @"username": @"taro yamada" }; User *user = [[User alloc] init]; user.id = jsonDictionary[@"id"]; user.name = jsonDictionary[@"username"]; この手のマッピング用ライブラリはたくさんあるんですが、探した中ではRPJSONMapperが使いやすそうでした。 マッピング定義が辞書で簡単に書ける マッピング定義を一箇所に書ける トランスフォーム（型変換）が出来る 例えばJSONリストをマッピングしてみる。 @implementation Note @propert
「チーム開発に役立つstubcell」ってタイトルでCodeGrid 2周年パーティでLTしてきた。 - from scratch
CodeGrid 2周年パーティでLTしてきました。 2周年おめでとうございます！！ TL;DR stubcellというjsonを返すことに特化したstubサーバーを作りました 内部的にjson5を使うことで定義ファイルにコメントを書くことができ、開発者間のコミュニケーションの補助になる grunt, gulpからstubサーバーを使うことができるため、フロントエンドタスクランナーと相性が良い 発表資料 stubcell 概要 いわゆるJSONを返すことに特化したstubサーバーです。 チームで開発する時に、APIサーバー、クライアントサイド、websocketサーバーといった感じに複数の役割を複数の人数で請け負って同時並行開発することが多く、APIのエンドポイントがなくてもクライアントサイドやwebsocketでも開発できるようにするためにstubcellを作りました*1。 また複数人で
koi_zoom1, オープンデータをやっている人は、過去にWSDLとかSOAPとかが上手く流行らなかった理由を知っておいた...
オープンデータをやっている人は、過去にWSDLとかSOAPとかが上手く流行らなかった理由を知っておいた方が良いと思う。 XMLがでてきて廃れてきた理由も。 結局、ちょっとリッチなCSVであるJSONのやりとりが今は主流。 LODってWSDLと同じ思想な感じがして同じ衰退の道をたどりそうなんですよね。 WSDLの方は「サービスをノードからたどれるようにした」のに対して、 LODは「データをノードからたどれるようにした」 でも、実際にノードをたどる必要はなくて直接そこからデータを抜き出すのが主流。 サービス同士をつなげようとしたのがWSDLで、でもプログラマは自分でプログラムを組んでサービス同士をつなげてしまう。 LODはデータ同士をつなげようとしていて、でも実際はプログラマは自分でデータをつなげる方が楽、と思いそうな気がするんですよね。 オープンデータの資料を読むとLODにするのが偉い的な書
HAProxy で MySQL のヘルスチェックをちょっと便利にする - 酒日記 はてな支店
MySQL で slave を複数台立てて参照分散するには、HAProxy を利用してロードバランスと切り離しを行うと手軽に使えて便利です。 option mysql-check という設定で、HAProxy 自身が mysqld に接続してヘルスチェックが可能です。 listen mysql-slave bind 127.0.0.1:3307 mode tcp option mysql-check user haproxy balance roundrobin server slave1 192.168.1.11 check server slave2 192.168.1.12 check server slave3 192.168.1.13 checkなのですが、この設定だと以下のように少々不便なことがあります。 mysqldに接続できるかどうかのみを死活の判断にしているので、レプリケ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsのレスポンスをjsonに固定しながら、スタックトレースもログに残す - Qiita
DeNA Engineering - DeNAエンジニアのポータルサイト
GitHub - samskiter/KiteJSONValidator: A native Objective-C JSON schema validator
GitHub - ant0ine/go-json-rest: A quick and easy way to setup a RESTful JSON API
