ブラウザで適当なランダム文字列 | blog.jxck.io
Intro テストや仮実装で、適当なランダム文字列が欲しい場合に便利なスニペット。 random string DEMO // with random btoa(Math.random()) // => MC44NzEwODQwMjA1NDA2MTE4 // with crypto btoa(crypto.getRandomValues(new Uint8Array(16))) // => MjQ2LDE0NSwxNzAsMjQ0LDY4LDg3LDMzLDE0NiwxNzcsNjAsMTUyLDE3MSwxNTAsMTcsMTA4LDEwNA== // base64 has `=` remove them btoa(Math.random()).replace(/=/g, "") // => MC45NTM0NTM2OTY3MTc5MDY0 // lower case btoa(Math
.mjs とは何か、またはモジュールベース JS とエコシステムの今後 | blog.jxck.io
Intro 長いこと議論になっていた ES Modules の Node における扱いに一応の決着が付き、 .mjs という拡張子が採択された。 この拡張子の意味と、今後ブラウザと合わせて Universal JS を実装していく上での作法が見えてきたことになる。 合わせてエコシステムが対応していくことで、長年の夢だった JS のモジュール化を進めていくことができるだろう。 ES Modules 徐々に揃いつつある ES Modules(ESM) の仕様は TC39 で行われており、その仕様については主に以下のような部分になる。 import や export と行った構文 module 内はデフォルト strict mode module でスコープを閉じる module 内の this は undefined etc 逆に以下は TC39 での策定範囲外となる どう Module を読
Fetch の中断と Promise のキャンセル方法の標準化 | blog.jxck.io
Intro XHR から fetch() に積極的に移行しづらかった最大のミッシングピースとして、中断できないという問題があった。 これは、 fetch() が選んだ Promise ベースのインタフェースにおいて、キャンセルをどうするかという議論と絡み、長く決着が付かずにいた問題である。 最近、やっと話が前進したので、ここまでの経過を解説する。 Fetch のミッシングピース fetch() は、ブラウザが発行するリクエストと、取得するレスポンスを扱う低レベルなインタフェースとして策定が始まった。 DOM の API が Promise ベースに移行しつつある流れを汲み、 fetch() もまた Promise を返す関数一発スタイルになった。 クラスからインスタンスを生成しメソッドを呼ぶ XHR スタイルでは、インスタンスを再利用した場合の挙動などを含め、オブジェクトのライフサイクルを
Web Budget API と Web に導入されつつある Budget と Cost の概念 | blog.jxck.io
Intro PWA の普及により、バックグラウンド処理をいかに制限するかといった課題が生まれた。 その対策として、バックグラウンド処理における Budget と Cost の概念が提案され、それを扱う Budget API の策定が進んでいる。 基本概念と現時点での API 外観について解説する。 Update 提案されて以降長いことアップデートがなかったが、 Mozilla Standard Position をリクエストしたところ、仕様が消えていたことがわかった。 https://github.com/mozilla/standards-positions/issues/73#issuecomment-373681407 元のリポジトリに Issue で現状を問い合わせたところ、結局開発者からの支持が得られず、 Obsolete されたとのこと。 blink-dev では Intent
JavaScript における文字コードと「文字数」の数え方 | blog.jxck.io
Intro textarea などに入力された文字数を、 JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、 BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID
mixed contents 対応を促進する CSP ディレクティブ | blog.jxck.io
Intro HTTPS 移行の問題点の一つに、 mixed contents への対応がある。 逆に mixed contents の発生を恐れ、 HTTPS に移行できないサービスもあるだろう。 本エントリでは mixed contents の正しい理解と、その検出や解消に利用できる可能性のある、 CSP の Upgrade-Insecure-Request および、 Block-All-Mixed-Contents を解説する。 mixed contents HTTPS で配信されたコンテンツが、サブリソースとして HTTP のコンテンツを含む場合、これを mixed contents という。 HTTPS は MITM に対する耐性があるが、 HTTP は MITM への耐性がないため、 mixed contents の状態ではサブリソースを起点にメインコンテンツへの改ざんが成立して
「Socket.IO は必要か?」または「WebSocket は通るのか?」問題について 2016 年版 | blog.jxck.io
Intro 「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。 これは、 WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、 Web を取り巻く状況は変わったが、変わってないところもある。 念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、 ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは 最初に、なぜ 繋がらない ことがあるのかを、きちんと把握したい。 まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく
Passive Event Listeners によるスクロールの改善 | blog.jxck.io
Intro DOM のイベントリスナの仕様に Passive Event Listeners というオプションが追加された。 このオプションは、主にモバイルなどでのスクロールの詰まり(Scroll Junk) を解決するために導入されたものである。 今回は、この仕様が解決する問題と、本サイトへの適用を解説する。 Passive Event Listeners Spec Scroll Event の PreventDefault() 画面のスクロールに合わせたインタラクションを実装する場合、 Scroll Event にイベントリスナを登録する。 典型的な例では touchstart や touchend をフックし、その中で DOM の操作などを実施するなどがある。 場合によってはイベントリスナ内で preventDefault() を呼ぶことで、スクロールそのものを止めることもできる。
中級者向け Service Worker Tutorial | blog.jxck.io
Intro Service Worker の初心者向けのチュートリアルや、使ってみた系のエントリも増えてきました。 しかし、 Service Worker は通常のブラウザ用 JS の開発と少し経路が違い、慣れるまで開発やデバッグもなかなか難しいと思います。 そこで特に難しい部分、そして分かっていないと実際にデプロイした際に難しいと思う部分について、実際に動きを確認しながら解説したいと思います。 なお、 Service Worker の基本的な概念などについては、他のチュートリアルなどを見て理解している前提で進めます。 思いつきで撮ったので色々ミスも有ります、また Chrome Dev Tools の UI はどうせ変わるのでそのつもりで見てください。 TODO になっている動画は、そのうち撮って追加します。 List claim controllerchange updatefound
h2o で https/2 のデプロイと設定 | blog.jxck.io
Intro 土台がだいたいできたので、このサイトを h2o にデプロイした話。 h2o 以前は nginx を使っていたけど、年末に旧ブログの方に書いた Cache-Aware Server Push を試したかったから。 HTTP/2 Push を Service Worker + Cache Aware Server Push で効率化したい話 これは現在 httpbis にドラフトとして上がっており、議論が進んでいる。 Cache Digests for HTTP/2 まだ Cookie での実装は残っているので、このサイトで対応して行きたい。 証明書 実は .jxck.io に対するワイルドカード証明書を買っている。 したがって、 Let's Encrypt は使ってない。 これは Podcast のドメインのほうでやっていこうと思っている。 ドメイン 今までは jxck.io だ
Resource Hints API でリソースの投機的取得 | blog.jxck.io
Intro Resource Hints とは現在提案されている以下のドラフトであり、ブラウザに「次に必要となるリソースを教える」ことで、投機的な取得を行う API 群である。 https://w3c.github.io/resource-hints/ 主に以下がある。 dns-prefetch preconnect prefetch prerender 今回は本サイトでこれを適用した話。 投機的なリソース取得 例えば、ログインページの次には、そのサービスのメインページに遷移する頻度が高い。 そして、メインページでは、以下のような追加のリソースが必要になるだろう。 追加の JS 追加の CSS 追加の Image 追加の API アクセス それぞれを DNS 解決 -> TCP 接続 -> リソースのフェッチ、と繰り返していくと、イニシャル表示は必然的に時間がかかる。 ところが、この遷移に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
