ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
次世代 Web カンファレンス 2019 開催告知 | blog.jxck.io
Motivation 「Web について話す場」 というか「Web そのものをテーマにした場」というのが、意外と少ないなとずっと思っていました。 (もちろん、結果として Web について話しているカンファレンスや勉強会はたくさんありますが。) そして、スライドなどを用いて何かを「発表する」ニュアンスではなく、進化の早い Web で「今何が起こっているか?」と「これからどうなっていくのか?」という、答えの無いもの、でもみんなが気になり考えていること、今だからこそ考えないといけないことを真っ向から議論する場というのが、もっとあっても良いのではないかと考えていました。 今回開催するカンファレンスは、この「議論」だけからなるものです、それ以外のことはしません。 この趣旨に賛同してくださった、各分野のプロフェッショナルに協力頂き、「次世代 Web カンファレンス」として、開催させていただくことになり
Bookmarklet という一番身近な自動化技術 | blog.jxck.io
Intro 「毎回やるなら bookmarklet にでもすれば?」と言ったら、後輩が「そんな便利なことできたんですね、知りませんでした」と言っていた。 そんな時代にこそ、今更だれも解説しないであろう、 bookmarklet という技術についてもう一度書いておく。 Bookmarklet 簡単に言えば、 JS を書き、それを Bookmark として登録すれば、クリックするだけで現在のページでそれが動くというものだ。 ブラウザ上で何かを自動化したいと思うなら、最も簡単に実現できる便利な技術だろう。 似たような手法ではブラウザの Extension などもあるが、 Bookmarklet の良いところは一切誰にも邪魔されないというところだ。 開発者登録も、ストアへのアップロードも、難解なドキュメントを忖度して煩雑な設定ファイルを書く必要もない。 開発者ツールで、「こんなことできないかな」と
予約済みドメイン (.example, .localhost, .test) について | blog.jxck.io
Intro 特別なドメインとして予約され、特定の用途で使用可能なドメインとして、 .example .localhost .test などがある。 localhost の Draft や、 gTLD である .dev が Chrome で Preload HSTS になったなどの動きを踏まえ、これらの意味や用途を解説する。 ドメインを利用する上での注意 ドメインは、レジストラなどを通じて取得するため、インターネット上では好き勝手に取得することはできない。 しかし、自分で設定可能な DNS や hosts ファイルなどを使えば、任意のドメインを任意のアドレスに解決させることができる。 例えば、自分が適当にリクエストのテストを行うためのドメインを hosts ファイルに設定し、ループバックアドレスに解決して流していたとする。 このドメインがたまたま実在するものだった場合、そのテストを他のユーザ
ネットワーク中立性について #NetNeutrality | blog.jxck.io
Intro US では #NetNeutrality について話題になっている一方、日本ではさほど話題になってないように思う。 インターネットを基盤としている Web 開発者にとっても、いつまで他人事でいられるか怪しい。 事態そのものがあまり知られてないかもと思い、決して精通しているわけではないが紹介する。 ネット中立性とは 簡単に言えば、ネットワーク環境を提供するプロバイダが、そのネットワークを流れるデータについて、恣意的なコントロールを しないように というルールだ。 この中立性が担保されている以上、プロバイダはそのネットワークを流れるパケットがたとえなんであれ区別しない。 しかし、もしこの中立性が担保されないとどうなるか。 例えば、プロバイダが同時にビデオチャットサービスを展開しており、そのプロバイダと契約しているユーザには、競合のビデオチャットが低速回線でしか利用できないようにする
WebRTC 1.0 に向けたロードマップ | blog.jxck.io
Intro Google の Product Manager である Huib Kleinhout が、 disscuss-webrtc の ML に以下のような投稿をした。 Completing WebRTC 1.0 WebRTC 1.0 を年内に終わらせるためのロードマップ(Chrome の改善を含む)を提示している。 このロードマップに期待を寄せ、簡単に現状を振り返りつつ紹介する。 Completing WebRTC 1.0 2015 年の TPAC あたりで、すでに WebRTC 1.0 を 2015 年内に完了する目標は掲げられていたが、結果諸々の問題を解決し切れず 2017 年を迎えた。 しかし、今回の投稿では、いよいよこの作業に終止符を打つためのロードマップが挙げられている。 WebRTC の現状 先に現時点の問題について整理する。 WebRTC は主に、 IETF が策定す
Web Share API | blog.jxck.io
Intro Web Share API が Origin Trials を卒業したという知らせが届いた。 コンテンツを他のサービスなどと連携するこの API について紹介する。 Web Share ブラウザで開いている Web コンテンツを、他のサービスやアプリと連携するための方法は、以前から検討されていた。 主だったものとしては、すでに策定は止まっているが Android の Intent を参考にした Web Intents が挙げられる。 Web Share API は、 Web コンテンツと SNS やメールなどとの連携を主目的とした、より簡素で軽量な API となっている。 DEMO 動作するデモを以下に用意した。 (まだ Origin Trials のトークンはそのままになっている) http://labs.jxck.io/web-share/ API API は非常に簡素だ。
HTTP の新しいステータスコード 103 Early Hints | blog.jxck.io
Intro これは、 http2 Advent Calendar 2016 の 16 日目の記事である。 HTTP に新しいステータスコード 103 Early Hints が追加されようとしている。 HTTP/1.1 および HTTP2 双方と関わり、リソース配信の最適化に利用することができる。 いったい何のために必要なのか、どういうメリットが考えられるかを解説する。 HTTP2 Push の復習 まず HTTP2 の Push について復習する。 H2 Push は、簡単に言えば PUSH_PROMISE フレームを用いて、レスポンスよりも先に依存するリソースを返すための仕様である。 例えば /users のレスポンスは script.js と style.css をサブリソースとして含んでいるとする。 HTTP2 では SQL を発行して Users の一覧を取得している間に、先行し
Google Developer Experts (GDE) になりました | blog.jxck.io
Intro Google の中の人からお声がけ頂き、 Google Developer Experts (GDE) に Web Technologies の Expert として Join することになりました。 GDE GDE は、簡単に言えば Google の技術についての啓蒙などを行う、社外アドボケート的な位置づけである。 https://developers.google.com/experts/ 各自専門領域(Android, GCP etc)があるが、自分はやはり Web Technologies ということになる。 Web に関する多くが標準技術であるため、 Google Developer Experts という名だが、別に Google や Chrome に限った内容を扱うわけではない。 活動 実際に何をするかというと、特に明確なタスクを詰まれるといったわけではないとのこ
「Socket.IO は必要か?」または「WebSocket は通るのか?」問題について 2016 年版 | blog.jxck.io
Intro 「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。 これは、 WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、 Web を取り巻く状況は変わったが、変わってないところもある。 念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、 ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは 最初に、なぜ 繋がらない ことがあるのかを、きちんと把握したい。 まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく
SQL でファイル検索するコマンド selects を書いた話 | blog.jxck.io
Intro UNIX コマンドを SQL で抽出できるツール qq を作った。 というエントリを読んで、そういえば似たようなものを作ってたなと思い出した。 自分の dotfiles の中にある、便利コマンド集の中にある selects についてである。 このコマンドは SQL という検索を記述的に表現する共通言語をファイル検索に応用し、 Ruby の動的言語として表現力を使って実装したものといえる。 その実装方法と実行例などについて記す。 selects 結論からいうとこういうコマンドだ。 $ selects mtime, size, basename from './entries/**/*' where extname '==' '.md' and size '>' 1000 order by mtime 2016-07-06 22:45:44 +0900 18437 web-font
Cache-Control の Immutable 拡張によるリロード時のキャッシュ最適化 | blog.jxck.io
Intro ブラウザはリロード時に、 max-age に満たないキャッシュを持っていても Conditional GET によってキャッシュの Validate (有効性の問い合わせ)を行う。 Cache-Control Extension として提案されている Immutable 拡張は、キャッシュが max-age 内であればリロード時もキャッシュヒットさせる拡張である。 このヘッダの効果と、本サイトへの適用について記す。 Cache-Control Cache-Control に max-age を指定することで、ブラウザにリソースをキャッシュさせることができる。 このキャッシュは max-age の期間内は fresh とみなされ、 fresh であればサーバへの問い合わせなく再利用される。 サーバへの問い合わせ(RTT)が無いため、事実上最速のリソース取得となる。 Reload
zopfli で静的コンテンツの gzip 配信と Content/Transfer-Encoding について | blog.jxck.io
Intro HTTP では Accept-Encoding と Content-Encoding でのネゴシエーションにより、 gz などで圧縮したコンテンツを転送することができる。本サイトでは zopfli を用いて gzip 形式の配信に対応した。 Accept-Encoding クライアントが Accept-Encoding: gzip を指定して来た場合、サーバは Content-Encoding: gzip を付与し、 URI に指定されたコンテンツを gzip 圧縮して送信することができる。 特にテキストベースの HTML, CSS, JS などは、この圧縮の効果が高く、ペイロードが小さくなるためパフォーマンスの向上が期待できる。 逆に、 PNG, JPEG など圧縮形式の画像などについては、オーバーヘッドが発生しサイズが増える可能性もあるため、対象フォーマットの選択には注意が
HTTP2 を前提とした HTML+CSS コンポーネントのレンダリングパス最適化について | blog.jxck.io
Intro Chrome が予定している <link rel=stylesheet> の挙動の変更について、 Google Chrome チームの Jake が、興味深いブログを上げている。 The future of loading CSS この内容は、単に Chrome に対する変更だけではなく、 HTTP2 によって変化する最適化手法と、それを最も活かすための HTML, CSS の構成についてのヒントがある。 今回は、この内容を意訳+補足解説し、本サイトに適用していく。 HTTP/1.1 時代の CSS HTML 自体がコンポーネントを意識した作りになっている場合は、自然と CSS も class などを使いコンポーネント単位に作ることができるだろう。 しかし、 HTTP/1.1 では、リクエストの数を減らすために全ての CSS を 1 つ(もしくは少数個)に結合する最適化が主流だ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
