  |
はてなキーワード: Jsonとは
英国での事例の顛末を読んでから、東洋経済オンラインのJSONよろしく児相をバッサリ断罪するコラムをご覧ください。
児童虐待死事件が起きた時に児童保護関係の職員を無闇に非難すると果たしてどのような顛末になるのか、イギリスの事例です
マシュー・サイド 『失敗の科学』第5章「犯人探し」バイアス より
https://twitter.com/yuiseki/status/1005274185034186754
https://toyokeizai.net/articles/-/224517
関連
『「かわいそうだ！なぜ救えなかった！」という電話が香川県の児童相談所や本課にバンバンかかっています』『その対応に追われることで、今、保護が必要な子どもたちへの対応ができにくくなっている』
https://togetter.com/li/1235452
虐待される子を救うためにはまずその親を救わねばならず、まずその親を救うためには児相をも救わねばならない。
はじめて psd や ai を扱ったとき、なんか「クリエイティブな業界人」になった気がして嬉しくならんかった？
やったことといえば初心者向けチュートリアルの最初のやつやって保存しただけだけどな。
みたいな。
俺がはじめて json 知ったのは、打ち合わせでなんか賢そうな奴らが
みたいな会話してるの聞いたときだったな。
もっと細部の理解できない会話をしていたはずだが「ジェイソン」という言葉にインパクトは頭一つ抜けてたな。
総じて２文字って格好いいのが多い気がするな。
ai 以外にも py とか rb とか弄りたての頃は「お前らは知らないだろうけどこれヤバいファイルなんだぜ？」とか思いながら作業するとテンションあがる。
大学の同級生（全然別業界に就職）とかが俺の後ろで「ほえ～～～」とか感心しながら見てるイメージ。
http://developer.hatena.ne.jp/ja/documents/bookmark/apis/getinfo
には2種類の取得方法が書かれているが、
例:) http://b.hatena.ne.jp/entry/json/http://www.hatena.ne.jp/
例:) http://b.hatena.ne.jp/entry/json/?url=http%3A%2F%2Fwww.hatena.ne.jp%2F
ひとつ目の書き方が使えなくなった。
渡すURLの中に?記号が含まれていると、それ以降を無視してしまうように見受けられる。
例えば
http://b.hatena.ne.jp/entry/json/https://www.jiji.com/jc/article?k=2018051601002&g=prk おかしい
http://b.hatena.ne.jp/entry/json/?url=https://www.jiji.com/jc/article?k=2018051601002&g=prk OK
Excelを持っているならはてブのJSONデータをそのまま取り込めるそうだからそのデータを使ってブクマが付いた時間のグラフが描けそう。
例えばこんな感じでJSONデータが取れる。 http://b.hatena.ne.jp/entry/jsonlite/https://anond.hatelabo.jp/20180315232737
Excel持ってないならスクリプトでCSVにしてしまえばいい。
rubyスクリプトだとこんな感じ。(Mechanize無し版に差し替え。なぜMechanizeを使っていたかと言うとはてブがUser-Agentが空だと値を返してくれないから。ちょっと長くなるが自前でUAを渡すようにした。)
#!/usr/bin/ruby
site = ARGV[0]
json_uri = URI.parse("http://b.hatena.ne.jp/entry/jsonlite/%s" % [site])
response = Net::HTTP.start(json_uri.host, json_uri.port) do |http|
http.get(json_uri.path, "User-Agent" => "Mozilla/5.0")
end
json_data = JSON.parse(response.body)
json_data['bookmarks'].each do |bookmark|
puts [bookmark['user'], bookmark['timestamp'], bookmark['comment'], bookmark['tags'].to_s].to_csv
end
引数に取得したいページのURLを入れる。hatebuapi-csv.rbという名前で保存したとしたらこんな感じで実行。
% hatebuapi-csv.rb https://anond.hatelabo.jp/20180315######## ＞ 結果.csv
大企業がクライアントの案件を受注したらしく社内説明会でどんなものを作るのか聞いてきた
詳しいことはもちろん書けないんだが、大雑把にいえば、その社内でのやることに応じたシステムが１０や２０とある
それぞれ独自のフォーマットのデータを扱うからシステム間のフォーマットを変換するシステムが必要のようでそれを作るらしい
こういうのは大きいところならよくある話だとか
そして今回作るようなシステム間のデータの相互変換のようなシステムはすでにクライアント社内にいくつもあるらしい
さらにはそれら変換するシステム同士をつなぐシステムというものもあるらしい
それぞれのフォーマットは別だが中身はおなじということが多いらしい
それってなんか無駄すぎない？
フォーマットをXMLとかJSONとかTSVとかの汎用フォーマットで統一して各システムが必要な部分だけをみればいいんじゃないの？
お金もらえるわけだから無駄であろうと作るのだろうが、無駄なものがどんどん膨らんで行きそうな気がして仕方がない
なんかシステム作る側があとから変換システムも作ってお金もらうために独自フォーマットを採用しているように思えてくる
日本の IT がダメとか言われるのも価値のある新しいものを作るのじゃなくてこんな無意味なものをいっぱい作ってるからなんじゃないかなーとも思った
クライアント側が過去のものをそのまま使いたいとか変な要望を無理に通したせいでこんなことになってきたということもあるのだろう
私がいるところは、プログラマ/システムエンジニア、フロントエンドエンジニア/バックエンドエンジニアとかの区分がなくひとりでなんでもやるところです
一応フロントエンドが好きで得意だと自称はしているものの一般的なフロントエンドってどこまでするのでしょうか
デザイナがするような部分
ここは当然でしょう
最近では SPA のページも多いので単純な HTML と JS ではなくフレームワークを必要とされることもあります
SEOの都合などでJSレンダリングじゃなくサーバサイドレンダリングで、サーバから受け取るHTMLの時点で表示できる状態になってることを依頼される場合もあります
その場合はサーバサイド言語に応じたテンプレートエンジンも使います
PHP なら Blade、Python なら jinja、 Node.js なら ejs という感じ
JS のコードをテストしたり gulp などのタスクランナーや webpack などバンドルツールを使うので OS のコマンドラインのツールも使える必要があると思います
サーバサイドの言語は別の人が作るにしても自分の環境でそれを動かすためにサーバ構築は出来たほうがいいでしょう
VM に OS のインストールしてウェブサーバをインストールしたり
Vagrant, Ansible 等で管理されているなら、設定ファイルを書くことはないにしろ実行する方法やエラーが起きたときの簡単な対象方法くらいは知っていないと不便かと思います
ウチの場合は各自LinuxをVMにインストールして Ansible でという使い方なので気づきませんでしたが、考えてみたら全部設定済みの VM データを配布してくれるということもあるのかもしれません
データによって画面表示を変えるときに、それに応じたデータを作って画面を確認したいことがあるので、mysql や postgres などなどデータベースの知識も必要になることがあります
SQL 書けなくても pgadmin みたいな GUI ツールで表を書き換えればいいのですが最低限の仕組みは知っていないと苦労しそうです
完全にフロント/バックが切り離されてるところなら、フロントエンド開発者向けにデータベースは使わずテンプレートエンジンに渡ってくるデータを好きに設定できる機能が用意されてるのかも？とも思います
サーバサイドの処理は不要でクライアントサイドの動きのみを作るわけですから、決まった場所の JSON ファイルのデータがそのまま使われるならデータベースの存在を知らなくてもいいですし
ここまでできたらバックエンドよりフロントエンドのほうが何でも出来る人みたいに思えます
あとはサーバサイド言語を書ければもうサービスが作れてしまいます
でもこれぐらいできないとすごく不便で、すぐに他の人に頼らないといけなくなるように思います
サーバ冗長化とかそういった部分はかかわらなくてもいいと思いますけど、Linux やデータベースなんかは自分でどうにかできないと周り誰もいないときに動かなくなったら作業進められななんてことがありそうですし
もう一つの方法としては、javascript版だ。
https://gist.github.com/bellbind/d9dc9ccdd4a8735a9990
２倍固定だけど。
デモページで試してみたら、javascriptがicabやらsafariでは動かない。
かろうじてFifefoxやchromeで動く。
最初ダウンロードして、OSXのweb共有で試してみようと思った。
→動かない。単純拡大の方はスパッと表示されるが、その下の表示が "Progress: initialize worker..." のままで停止。
Apacheの設定を変えるといいのかもしれないが、あくまで仕事の機械だしね。
結論としてはダウンロードしたHTML書類を、Finderから右クリックしてFifefoxで開くとなぜか動くというのが確認できた。
へーってなった。
（ちなみにHTMLをエディタで開いてjsonをgithubのURLにしたらweb共有からでも動くのは確認した。
ただし外部サイト側に迷惑をかけないためという主旨なんで元に戻している。それでいいなら公式にブラウザでアクセスするので
プログラマなんだけど、なんでも揃えようとしてる人がうざい
よくあるのが、JSON とかオブジェクト系の記述するところで、 「:」とか「＝＞」みたいなのの位置
揃えられると一見すると見やすいが、金額みたいに揃ったみやすさが必要ないところでされると面倒
10行並んでたら1つ変えたのが原因で10行とも変えないといけなかったりする
面倒だけどツール使えば揃えること自体は楽にできるからこれはまぁいい
だが、バージョン管理ソフトでの変更行数が無駄に増えるのでパット見たときに結構大きな変更してるように見えたりするからちょっとイヤ
さらに grep かけようにも空白数が不定だから正規表現にしないといけない
んだけど、まあここまでは別にいい
この揃えるときに
aaa : { bbbb : 100 ccccc: 200 }, dddd : { e: : 300 }
みたいに（フォントによっては揃ってなく見えるかも）、ネストが違うのに全部を揃えようとするの、ホントやめろ
わかりづらい
上の例みたいなシンプルだと困らないが複雑な構造になってるとかなり見づらい
上でいう aaa と dddd の行が10行程度離れていたら、ここを揃えても全くきれいに見えないし無駄
bbbb と ccccc みたいなときだけならまあ許せる
仏の顔も三度まで、
(1) 文字数を合わせようとする
上で書いたみたいなのは文字数が違うから合わせるためにスペースを入れる必要がでる
きれいなのはわかる、だが無理やり合わせようと単語を探し始めるとかありえない
5つ項目があって、4つが6文字の単語で残りの1つが4文字だったとする
無駄な上に、本来のそれに適した単語じゃないのを無理やり使うのでわかりづらい
揃ってることはパット見綺麗でもプログラムみたいのだと、単語まで似てると気づかないミスが出て来る
beer と bear、 form と from、 fall と fail みたいな見た目が似てる単語と、見た目が全く違う単語の比較ではミスの数が明らかに変わると思う
なのに、 enum みたいな選ぶタイプのもので、数文字違うだけの似た見た目の単語を探してきて選ぶとか、ミスを誘発しようとしてるのかと言いたい
(2) 単語の語尾とか
(1)のように大半が揃ってると残りも無理やりそうしたいということで、単語を勝手に変化させたものがある
例えばだが、語尾が1つを除き全部 -ly になってたとする
そうすると残り一つに無理やり ly をつける
なんなの？イン踏みたいの？ラッパーなの？？
そもそも名前みたいな固有名詞にすらそんなことしてるから意味不明にもほどがある
上の時点で英語を完全無視で英語力のなさはわかっただろうが、さらにこういうのもある
過去形には ed 、複数形には s のようなルールには単語によっては特殊な形をするものがあるのはもちろん知ってると思う
プレフィックスに is つけるみたいな単語の組み合わせ部分なら気にしないけど単語としておかしいから、自分で書くときに本来の形で書くとエラーでるからさらにイライラする
例えばこういうこと
readed, catched, taked, companys, boxs, mans, childs, fishs, classs
見てるとムズムズする
英語得意でない自分ですら違和感を感じるのに、これに何も感じないとか英語力ひどすぎると思う
まあエラーメッセージで don't have ～ とすべきところを has not ～ とか書いてたくらいだからなぁ
これが部下とか下の立場の人なら 「使う前にググってみて。おかしかったら『もしかして、～～』みたいの出るから」と言って直させるけど、上だからどうしようもない
間違ってますよー、と遠回しに言ってみたことはあるものの、直す気は全くないようだし、それどころか無邪気に揃えてやったぜみたいなこと言ってドヤ顔してるからホントどうしようもない
https://www.nasnem.xyz/entry/incorrect-comprehension-test
http://mubou.seesaa.net/article/453754579.html
どっちもとんちんかんなことを言っているので、この問題について解説。
1「輸出が伸び悩む中でも、和牛が人気の牛肉や、和食ブームを反映した緑茶や日本酒などは好調だ。」
2「輸出が伸び悩む中でも、和食ブームを反映した日本酒や緑茶、和牛が人気の牛肉などは好調だ。」
1と2を同じ意味に解釈することはできますか。と問われればイエスだが、全く同じですか。と問われればノーだ。
同じ意味に解釈したときの文章構造をJSON風に表記するとこうなる
輸出が伸び悩む中でも好調だ : [ { 和牛が人気の : ["牛肉"] }, { 和食ブームを反映した : ["緑茶","日本酒"] }, "など", "など", "など", //以下任意のなどが続く。"など"の中身はなんでも良い ]
輸出が伸び悩む中でも好調だ : [ { 和牛が人気の : ["牛肉"] }, { 和食ブームを反映した : ["緑茶","日本酒","など","など","など",] //以下和食ブームを反映した"など"が続く }, ]
2の文と同じ意味の文はどれですか、と問われれば1を選ぶが、
ジェイソンは、階層構造が持てるので、表形式やCSVより複雑なデータ構造を定義しやすい特徴があると思います。
この話は、途中で「危ない」の意味がすり替わっているので混乱してるんじゃないかな？
これが許可された場合に攻撃の危険性にさらされるのは「リクエストを受ける側」のサーバだ。
この場合、攻撃者である可能性を持つ「リクエストを投げる側」は不特定多数である。
2. ＜script src=""＞なら他ドメインも取れるよ ← まあわかる
3. じゃあここを動的に変えて、実体はスクリプトファイル(JSONP)で関数呼んでデータ貰おう ←！？
関数実行しちゃってんだぜ？
これが許可された場合に攻撃の危険性にさらされるのは「リクエストを投げる側」であり、先ほどとは攻撃者と被攻撃者が逆転している。
この場合、攻撃者である可能性を持つ「リクエストを受ける側」は、「リクエストを投げる側」が明示的に指定したサーバだ。
この問題は信用できないドメインに対して自分側からリクエストを送らないようにする、という明確な対策が可能である。
JSONPは、「リクエストを受ける側」にとってXMLHttpRequestでWebAPIを叩かれるよりも安全だからドメインを超えた通信が出来るわけ。
つまりこういうことね。
【XMLHttpRequestの危険性 (実際にはこの動作は禁止されている)】 ブラウザ←ーーー「攻撃者WEBサーバ」（悪意あるリクエストを投げるコードをブラウザに渡す） ーーー→「被攻撃者WEBサーバ」 (悪意あるリクエストに答えてしまう) 【JSONPの危険性】 ブラウザ←ーーー「WEBサーバ」（攻撃者WEBサーバへリクエストを投げるコードをブラウザに渡す。※このサーバは、攻撃者WEBサーバに悪意があることを知らない) ーーー→「攻撃者WEBサーバ」（レスポンスとして悪意あるコードをブラウザに渡す） ブラウザ←ーーー (悪意あるコードを実行してしまう)
