At the front 筆一本は いかにして実現したか?
- 結城 浩
- 執筆で生きていくには?
- 良い文章を書くには?
- 本に近い状態(印刷)で読んで、直すを繰り返す
- Vim,LaTeX,Git,Evernote,Simplenote,Slack
- ロングセラー > ベストセラー
- 大学時代に「ある程度の長さを持った文章を定期的に書こう」と意識していた
- 自分自身を含めたメタ分析(何を考えこの文章を書いたか)
- プログラムを書くためのプログラムに似て、「プログラミング言語の本を書く」ってい
うのは「言葉の本を言葉で書く」こと
- ECMA-262というJSの規格書は文章ではなくコンパイルしてコードとして読む
- 文書の上手い人は読まれたときにどう処理されるか予測できる人
- 自分の欲求を満たすのではなく読者の欲求を満たすことを考える
縁の下のUIデザイン 中国のスマートフォンアプリの共通項
- 池田 拓司
- カラフルなデザインが多い
- グラデーションを利用し下層へ導線を張る
- アプリ内でキャプチャをするとキャラが出てくる
- 住んでる場所、いる場所を指定できるUIが多い
- 佐藤 歩
- CDNの基本は、分散ネットワークによるキャッシュと配信
- CDNの分散ネットワークは、PoP(Point of Presence)と呼ばれる世界中に置かれたエッジサーバ群で構成される
- キャッシュ、伝送距離の短縮がメインの高速化
- アクセス集中時の安定化
- オリジンの通信費の削減
- HTTP/2の恩恵
- PoPが日本にあるかチェックしよう
HTTPキャッシュの基礎知識
- ローカルキャッシュ(ブラウザなど)
- シェアードキャッシュ(プロキシサーバー、CDN)
- ナビゲーションリソース(HTML,APIレスポンス)
- ブラウザでURLを入力したりリンクを選択したりしたときに発生する画面遷移に必要な最初のリソース
- 静的リソース (CSS、JavaScript、画像)
- 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