「PWA Night vol.3 ~PWAのミライや活用方法をみんなで考えよう~」で登壇してきた #pwanight
PWA Night vol.3で「Cache APIに触れる」というタイトルで登壇をしてきました。
PWA Nightは第2回のイベントページをどこかで発見して、予定に被っているなーと呟いたところ
#pwanight の予定が完全に他と被っていて悲しい。行きたかった。
— tiwu (@tiwu_official) February 27, 2019
主催者に拾っていただき、登壇もしたいとリプを送ったところなんとOKをもらって今回登壇させていただきました。
ありがとうございます!
vol.3の会場はオイシックスで、めちゃくちゃお洒落(壁に絵が書いてあった)(写真を撮り忘れた)。
懇親会ではオイシックスの野菜がいくつかあって(ちょうどテレビで見たトマトもあった)(゚д゚)ウマー だった
登壇資料
登壇内容はCache APIについて。
キャッシュはService Workerの機能ではないく Cache APIがやっていて、Service Workerはキャッシュから取り出して返しているという話
workboxとかでラップされているのでCache APIをあまり意識することは普段ないのかもしれない
それにしてもブラウザにキャッシュできる機構はLSとかIndexedDBとかCookieとかたくさんあるな・・・
「Meguro.es # 20 @ Drecom」と「【第8回】フロントエンド× ビアバッシュ初心者勉強会 酒がナイト in 銀座」でLTしてきた #meguroes #sakenight8
2つともほぼ同じような内容だったのでまとめてブログにしてみた。
会社のブログでよく書いているから、個人ブログのテンションがよくわからない・・・
Meguro.es # 20 @ Drecom
目黒周辺のES系勉強会
目黒.cssというのもあるらしくて、こっちも参加してみたい。
LTに申し込んだけど先着順で補欠だった
ただ、ツイッターで懇親会中に飛び込みLTもあるのでぜひということでLT資料作って参加(ありがとうございます!
会場はドリコムさんで、めちゃくちゃお洒落だった
ドリコムのこのカフェスペースみたいなところめっちゃいいな
— tiwu (@tiwu_official) 2019年4月4日
ご飯の自販機みたいなのもあるしイベント開催できる広さあるしよいな#meguroes
名札があってシール貼ったりして懇親会の話のネタにするのすごいいいアイデアだなと思った
懇親会はエンジニアらしく?ビールとビザ(最高
発表資料
デモURL
informal-meguro-es-web-components.netlify.com
こんなかんじだった。盛り上がりを感じて楽しかった
飛び込みLT #meguroes pic.twitter.com/eTVneM1Jib
— Meguro.es (@meguroes) 2019年4月4日
帰りに目黒駅近くの中本食べたら無事死んだ
【第8回】フロントエンド× ビアバッシュ初心者勉強会 酒がナイト in 銀座
酒がないとプログラム書けないという強い勉強会で見つけた瞬間申し込んだw
会場はリンクアンドモチベーションさんで、銀座SIX内でめちゃくちゃお洒落だった
いい感じにお酒飲んでLT聞いて、懇親会して、2次会行ってただただ楽しかった
始まりました(ビール2缶目)#sakenight8
— tiwu (@tiwu_official) 2019年4月6日
獺祭あるけどコップないのでラッパ飲み説#sakenight8
— tiwu (@tiwu_official) 2019年4月6日
発表スライドはMeguro.esとほぼ同じような内容
デモURL
informal-sakeganaito-web-components.netlify.com
発表資料について
両方Web Componentsの話
Web ComponentsはMeguro.esでは8割くらい知っていて書いたことある人は2割くらい
酒がナイトは1割くらい
ロゴとか表示するだけといったようなただの静的なコンポーネントなら作るのは本当に楽で1時間もかからない
VueやReactのような開発環境構築がいらないのが始めやすくて嬉しいと思う
動的な表示はconnpassのAPIがJSONPでそこに詰まったのとconstructor
とconnectedCallback
で詰まった。
APIで取ったあとにループして動的に表示させようとしたら値が渡せず悩んでいて(constructor
値を受け取る処理を書いていた)
constructor
に初期化時だけ呼ばれて、connectedCallback
はDOMに挿入されるたびに呼ばれるからこっちに書かないといけなかった・・・
凡ミスと発想が足りなかった・・・
WEB+DB PRESS Vol.109
At the front 筆一本は いかにして実現したか?
- 結城 浩
- 執筆で生きていくには?
- 良い文章を書くには?
- 本に近い状態(印刷)で読んで、直すを繰り返す
- Vim,LaTeX,Git,Evernote,Simplenote,Slack
- ロングセラー > ベストセラー
- 大学時代に「ある程度の長さを持った文章を定期的に書こう」と意識していた
- 自分自身を含めたメタ分析(何を考えこの文章を書いたか)
- プログラマーと通ずる(何を考えこのコードを書いたか)
- プログラムを書くためのプログラムに似て、「プログラミング言語の本を書く」ってい うのは「言葉の本を言葉で書く」こと
- ECMA-262というJSの規格書は文章ではなくコンパイルしてコードとして読む
- 文書の上手い人は読まれたときにどう処理されるか予測できる人
- 自分の欲求を満たすのではなく読者の欲求を満たすことを考える
縁の下のUIデザイン 中国のスマートフォンアプリの共通項
- 池田 拓司
- カラフルなデザインが多い
- グラデーションを利用し下層へ導線を張る
- アプリ内でキャプチャをするとキャラが出てくる
- 住んでる場所、いる場所を指定できるUIが多い
最新CDN入門
CDNとは何か
- 佐藤 歩
- CDNの基本は、分散ネットワークによるキャッシュと配信
- CDNの分散ネットワークは、PoP(Point of Presence)と呼ばれる世界中に置かれたエッジサーバ群で構成される
- キャッシュ、伝送距離の短縮がメインの高速化
- アクセス集中時の安定化
- オリジンの通信費の削減
- HTTP/2の恩恵
- PoPが日本にあるかチェックしよう
HTTPキャッシュの基礎知識
- ローカルキャッシュ(ブラウザなど)
- シェアードキャッシュ(プロキシサーバー、CDN)
- ナビゲーションリソース(HTML,APIレスポンス)
- ブラウザでURLを入力したりリンクを選択したりしたときに発生する画面遷移に必要な最初のリソース
- 静的リソース (CSS、JavaScript、画像)
- HTMLにより取得される
- Cache-Controlが基本
- public,max-ageなどはディレクティブという
- publicはCDNなどでシェアードキャッシュされる
- privageCDNなどでシェアードキャッシュされない
- no-storeはキャッシュされない(Fastlyはキャッシュする)
- immutableはリロード時もキャッシュを返す
- Expiresヘッダは古い規格で日付を指定する(Cache-Controlが優先される)
- 期限が切れたら有効性検証を行う
- 更新されていなかったら304 Not Modifiedを返す
- no-cacheは有効性検証をしてからキャッシュする
- must-revalidateは有効性検証時にオリジンサーバに到達できない場合は504 Gateway Timeoutを返す
- Etagレスポンスヘッダがあれば、検証時にIf-None-Matchヘッダをつける
- ハッシュを送ってサーバーでチェックする
- Last-ModifiedとIf-Modified-SinceはEtagとほぼ同じ(こっちは日付)
- stale-whilerevalidate=60を指定するとキャッシュが切れても1分は古いキャッシュを使う
- 裏でキャッシュ更新する意図で使われる
- stale-if-error=60を指定するとサーバーでエラーが起きていても1分はキャッシュを使う
- UAを見て同じURLでも違うコンテンツを返す可能性がある
- Varyヘッダを使ってCDNキャッシュをコントロールできる
- Fastlyは50ドルの無料枠がある
- Fastly内のキャッシュが利用されたかはx-cacheで確認できる
- オリジンサーバーはFastlyのみアクセスできるといった保護が必要(セキュリティ目線)
- Basic認証をVCL(Varnish Configuration Language)で付与する
- もしくはIP制限
- TLS配信
- Surrogateヘッダ
- Surrogate-Controlヘッダ
- SurrogateCapabilityヘッダ
- Surrogate-Keyヘッダ
- Surrogate-Keyヘッダ
- スペースで区切られたキーに従ってURLを関連付ける
- Surrogate-Key: key1 key2
- キャッシュパージ
- 有効期限を待たずキャッシュを削除する機能
- Fastlyは150ミリ秒で消せる
- ソフトパージするとTTLを0にする
- Surrogate-key単位で消せる
- シールドPOPという複数POPが存在する際のオリジンと通信する唯一のPOP
- FastlyはVarnishベール
- サブルーチンごとの処理が大切
- クライアントからのリクエスト情報に関するreq.*変数
- オリジンサーバからのレスポンスに関するberesp.*変数
- Fastlyからクライアントへのレスポンスに関するresp.*変数
- Fastly VCL boilerplateというテンプレートが準備されている
- VCL snippetsはスニペットを作って埋め込みができる
- Custom VCLは全体を直接いじれる
- API,Terraformも対応している
- CDN前提の設計が必要
- キャッシュサーバー、エッジサーバーの処理の委譲は根幹に関わる設計
- 誰でも同じ情報であるパブリックコンテンツとユーザーごとに異なるプライベートコンテンツを適切に分離する
- パブリックコンテンツは積極的なキャッシュとヒット率の向上を目指す
- TTLを更新頻度、反映遅延許容度に合わせて決める
- パージも利用する
- ESI
<body> <main> <!-- 通常のコンテンツ --> <esi:include src="/foo-contents.html" /> </main> <aside> <!-- 新着情報 --> <esi:include src="/bar-updates.html" /> </aside> </body>
- privateなものはシェアードキャッシュを禁止させる
- リクエストヘッダへのユーザー属性付与はABテストなどに利用ができる
- UAは数千パターンあるので正規化したフラグに変換する
- 同じURLでもUAとかで返す情報が違うので、そこも考慮する必要がある
- 静的リソースはrivvingというファイル名にハッシュ値とかを入れてキャッシュさせる
- SWはrivving適用しないほうが良い
- 画像は入稿されるものとUIのものは区別して戦略を考える
- フォントは強くキャッシュ
- 画像を最適に配信する
- リサイズやクロップ
- 画像の圧縮
- webpへの変換
- セキュリティも一部任せられる
- DDosやBotとか
- エッジコンピューティング
- Lambdaとか
- クライアントからCloudFrontへのリクエストおよびレスポンス
- CloudFrontからオリジンサーバへのリクエストおよびレスポンス
- クッキーを見てABテストしたり
- Cloudflare Worker
- SW形式
addEventListener('fetch', event => { let url = new URL(event.request.url); // リクエストヘッダに"X-Use-Dev"が含まれる場合は // ホスト名に"dev."を追加する if (event.request.headers.has('X-Use-Dev')) { url.host = "dev." + url.host; } // プロトコルはhttps固定にする url.protocol = 'https:'; // 変更したURLでオリジンサーバにリクエストする event.respondWith(fetch(url, event.request)); });
Kotlin
Puppeteer
- ヘッドレスchromeと扱うライブラリ