アプリとサーバーの通信にJSONではなくSQLiteを使うと幸せになれるかも知れない条件まとめ - アニマネ開発日誌
軽い気持ちで投稿したら、思わぬ反響を頂いたこの話。 賛否両論で色々な意見を頂きました。 問題点も含めてある程度メリット・デメリットが見えてきたので、最後にまとめてみます。 ブコメ、Twitterで色々と意見を頂いた方々ありがとうございました。 この場を借りてお礼申し上げます。 前回までのおさらい クライアントとサーバー間で何らかのデータの受け渡しをする時に、 よく使われるフォーマットとしてJSONやXMLがあります。 構造がシンプルなテキストで汎用性が高いため、あらゆるプラットフォーム間の差異を吸収するフォーマットとしてメジャーな存在です。 モバイルアプリも例外ではないのですが、JSONなどを使わずにSQLiteのDBファイルを直接渡してやりとりするというのが先日書いた記事です。 SQLiteはクロスプラットフォームな上に1ファイルで完結するので、1つのファイルで様々なプラットフォームから
PHPのJSONライセンス問題が一応決着 - hnwの日記
2012年頃に、PHPのJSONエクステンションのソースコード中に次のようなライセンス文言が含まれていると話題になりました。 The Software shall be used for Good, not Evil. これはJSONライセンスと呼ばれるライセンスの一文です。「このソフトウェアを良いことに使うのはいいけど、悪いことには使っちゃダメ」といったところでしょうか。 これはフリーソフトウェアの定義に反しており*1、各種LinuxディストリビューションでJSONエクステンションを配布できないことになるため、ちょっとした騒動になったというわけです。 本稿ではこのJSONライセンスへの対応が現在どうなっているかを紹介します。 各種Linuxディストリビューションの対応 PHPのJSONエクステンションはjson_encode()やjson_decode()などの重要な関数を提供するエクス
Googleスプレッドシートを簡易DBとして利用する - PHP+Ajax編 - Mach3.laBlog
この記事は賞味期限切れです。（更新から1年が経過しています） このお題は以前にも何度か関連記事を書いていますが、 いずれの方法もパフォーマンスがあまり良くなかったり、安定性に問題があるなどしました。 今回はその辺を解決する為のライブラリを考えてみるお話です。 やりたい事 書いてみたもの 基本的な使い方 Ajaxで利用する JSONPで利用する その他オプション・機能など 必ず気をつけなければならないこと まとめ : Googleスプレッドシートの活用について 「新しくなったスプレッドシートと簡易データベース化」でGhostsheetが使えなくなったと書きましたが、新スプレッドシートでもAPIが整備された様で、2014年11月20日現在では正常に動作する事を確認しています。但し、スクリーンショット類は古い物なのでご注意ください。（スプレッドシートIDの取得はURLを参照されるのが良いでしょう
1分でわかるjQuery $.ajaxによるJSON・JSONP読み込み方法
$.ajaxによるJSON読み込み方法 例えば以下のようなJSONの場合 [ { "version": "1.5", "codename": "Cupcake" }, { "version": "1.6", "codename": "Donut" }, { "version": "4.4", "codename": "KitKat" } ] $.ajaxでの読み込みは下記のようになる $.ajax({ type: 'GET', url: 'https://iwb.jp/s/js/data.json', dataType: 'json', success: function(json){ var len = json.length; for(var i=0; i < len; i++){ $("#a").append(json[i].version + ' ' + json[i].coden
JSON Viewer - Home
すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W
機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
WebアプリケーションにおいてJSONを用いてブラウザ - サーバ間でデータのやり取りを行うことはもはや普通のことですが、このときJSON内に第三者に漏れては困る機密情報が含まれる場合は、必ず X-Content-Type-Options: nosniff レスポンスヘッダをつけるようにしましょう(むしろ機密情報かどうかに関わらず、全てのコンテンツにつけるほうがよい。関連:X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記)。 例えば、機密情報を含む以下のようなJSON配列を返すリソース(http://example.jp/target.json)があったとします。 [ "secret", "data", "is", "here" ] 攻撃者は罠ページを作成し、以下のようにJSON配列をvbscriptとして読み込みます。もちろ
jqコマンドが実は高性能すぎてビビッた話
GWが始まりましたが、鎌倉のGWは観光客多すぎて逆に住民はげんなりして外に出なくなる感じです。とはいえ路地まで観光客が攻め込んでくることは少ないので、路地を散歩する分には天気がよくていい感じですね。ちなみに人力車のおにーさんはそういう味のある路地を知り尽くしているので人力車で移動するのはそこそこオススメです(ぼくは乗ったことないけど「こんなところも通るんだ!」ってところで見かけたりします)。 さて、jqというコマンドをご存じでしょうか。 jq jq is a lightweight and flexible command-line JSON processor. と書いてあるとおり、コマンドラインでJSONを扱うことができるコマンドです。で、今まさに仕事で巨大JSONと戦うことが多く、このコマンドが大活躍です。 とはいえ、ぼくの使い方としては「巨大JSONをキレイに整形して表示する」とい
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
SQLとJSONをNode.js上で組み合わせた新言語「ql.io」をeBayが公開
eBayが、JavaScriptアプリケーションからSQL文のような形式でデータベースへの問い合わせを記述できるDSL（ドメイン固有言語）のql.ioを発表。オープンソースとして公開しました。 現在、多くのWebアプリケーションが、バックエンドとのデータのやりとりにHTTPをベースにしたAPIを用いています。しかし、WebベースのAPIによってデータを取り出すのは、プログラマにとって実は手間のかかることです。 例えば、キーワードを入力すると関連する商品の名前、詳細、購入者の評価をユーザーに表示する、というWebアプリケーションでは、まずキーワードでデータベースを検索して商品IDを取得し、今度はその商品IDをキーにして名前や概要、評価の情報を取得する、といったように、APIを繰り返し呼び出す必要があります。 ql.ioはこうした内容をSQLのように分かりやすい記述で実現するだけでなく、複数の
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSON SchemaとPHP