タグ

ブックマーク / qiita.com/shibukawa (6)

  • Cache-Controlヘッダは仕様通り実装されていない? - Qiita

    最初に 次のエントリーで追試しました。エントリーの内容は古いです。一応Qiitaは履歴もとってくれるのでこの記事を上書きしちゃってもいいんですが、そうなるとコメントのコンテキストがわからなくなってしまうので、別記事にしました。エントリーも記録のために残します。 Cache-Controlヘッダは仕様通り実装されていない?(2) 編 HTTPのキャッシュの仕組みをいろいろ調べているのですが、よくわからなかったので実験してみました。 HTTP キャッシュの作成 14.9 Cache-Control 上記のサイトの説明によれば、no-cacheとmust-revalidateは非常に近い説明になっています。no-cacheはsubsequent requestと書いてあるので、.htmlから呼ばれる.css、.jsあたりのことまで(subsequent request)書いていると思われま

    Cache-Controlヘッダは仕様通り実装されていない? - Qiita
    suginoy
    suginoy 2018/04/23
    “正確には、ブラウザのリロードとナビゲードではキャッシュの扱いが違う場合があります。 ”
  • GraphQLは90%のウェブサービス開発者にはまだ時期尚早ではないか - Qiita

    PySpa統合思念体です。チャットで話をしたことのまとめです。何人かで雑に話をしたことのまとめで、特定の誰かの発言というわけではなく、一種の怪文書です。 さて、GraphQLが世間を賑わせ始めています。Facebookが開発し、GitHubも機能提供をし始めました。GraphQLはRESTの未来か?みたいな論調もありますが、新しいものが出てくると既存のものをサンドバックにして「まだそんな古いの使ってやがるのかよwwwww」みたいな煽りをするのはもはやウェブ界隈の風物詩になっていますが、そういう信者発言をして「ああ、あいつまた踊らされてるな」「あいつ技術を見る目がないな」みたいに思われないように、少し冷静にGraphQLの立ち位置や、今後予想される流れについて考えてみます。 LSUDsとSSKDs WebAPI The Good Partsでも紹介されていた概念として、Netflix社のAP

    GraphQLは90%のウェブサービス開発者にはまだ時期尚早ではないか - Qiita
    suginoy
    suginoy 2017/06/30
  • Cache-Controlヘッダは仕様通り実装されていない?(2) - Qiita

    Cache-Controlヘッダは仕様通り実装されていない? 自分の投稿へのフォローです。前のも一応残しておきます。 僕は見栄とか張るつもりはないので、分からないことは声を大にして「分からない」と叫んでいきます。「これはこうだよ」という正確な結果を教えてもらえるのが一番助かりますが、そうじゃなくても、不確かでも「これはこうじゃないかな?」という別の解釈とか、「こういうテストをしてみたら?」という提案でもあればまたテストを増やして検証していくのでぜひコメント欄を汚してください。 結果 テスト結果 テストプログラム 前回からの更新 そもそものきかっけは、no-cacheと、must-revalidateの違いが良くわからないということで実験してみたけど益々よくわからない!ということでした。 その後、Jxckさん、tzikさん、@tenpoku1000さんからコメントやら何やらもらったので追試し

    Cache-Controlヘッダは仕様通り実装されていない?(2) - Qiita
    suginoy
    suginoy 2017/06/29
  • JavaScriptはなぜトレンドが毎年変わると思われていたのか - Qiita

    JavaScriptはなぜトレンドが毎年変わると思われていたのか JavaScriptのエンジニャーは口を開くたびに出てくるツール名が違う、いつも環境設定をしている、みたいな話をよく聞きます。実際、それを揶揄するようなエントリーが人気だったりします。 とはいえ、JavaScriptを実際に使い込んでいる人は別にそんなに大きな変化だと思っていない節があって、台風は外周部ほど風速が速い、みたいな印象を感じます。 カンブリア紀のJavaScript ウェブサイトをパカパカ動かすための言語でした。DHTMLです。FireBugが出る前のJavaScriptを開発していた人類は、念力デバッグを駆使していました。あるいはalert()。 三畳紀のJavaScript prototype.js、jQuery、Closure Compiler、YUI、mochikit、Ext.jsなどの時代。JavaSc

    JavaScriptはなぜトレンドが毎年変わると思われていたのか - Qiita
  • オブジェクト指向と20年戦ってわかったこと - Qiita

    この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則? 3原則じゃなくて4では?みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav

    オブジェクト指向と20年戦ってわかったこと - Qiita
  • encodeURIComponentが世界基準だと誤解してた話

    URLをいじくるプログラムをいじっていて、仕様がよくわからなくて悩んだのでまとめます。 2/23: 追試部分を追記 2018/7/14: JavaScriptのURLSearchParamsと、GoのPathEscapeについて追記 ことの経緯 HTTPとはなんぞやとか、GETとPOSTがどうの、それぞれでパラメータがどういう経緯でウェブアプリケーション(とかCGI)に渡って来るのかぐらいは知っていました。で、ウェブでXHRでGETリクエストを送る場合にはJavaScriptのencodeURIComponent()で各パラメータをエンコードして、&でくっつけて、URLの末尾に?で付与すればいいんだよね?と思っていました。こんな感じに。 var finalUrl = [url, "?", encodeURIComponent("key"), "=", encodeURIComponent(

    encodeURIComponentが世界基準だと誤解してた話
    suginoy
    suginoy 2015/08/15
    "ERB::Util.url_encode, CGI.escape, URI.encode_www_form_component, WEBrick::HTTPUtils.escape_form, WEBrick::HTTPUtils.escape の順に%エンコードが少なくなります。obsolete 扱いなので数に入れなかった URI.escapeを使う人もまだまだ多い"
  • 1