00:07
はい、7月31日。最後の日ですね。日曜日、地獄浅久城を回りました。
本日も朝から、家の近くで救急車や何やらが走り倒しています。
僕の家の目の前が病院が近くにあります。
はい、ちょっと流れてる感じです。すみません。
ありがとうございます。ひめめのkeethことくわはらです。
では本日も朝活を始めていきたいなと思います。
今日もタイトルにある通りですけど、2つの記事を読みますと、
今日は朝一で、何だっけ、
もうやばい最近名前がほんと出てこなくてひどいですね。
Twitterで流れてきた日本語の記事ですね。
シフトさんの技術ブログですけど、
なぜ我々はユニットテストを書けないのかっていうところが流れてきまして、
竹ペペさんが流してくださったんですけど、
これがちょっと良さそうだったので、ついにタイムリフに流れてきたので、
そのを読んでいこうかなと思います。
もう一つは技術的なところですけど、
僕が最近魅了されたクラウドフレアワーカスのブログの中から
How the cash worksっていうところですね。
前回はHow the cash worksっていうところを読んだんですけど、
今回はそのCash worksのところを読んでいけたらなと思いました。
じゃあ早速いっていきましょう。
ツイートしませんでしたね。
ツイートしなかったのでツイートします。
ツイートします。
やりますよというツイートをしておかないといけないので。
違うか。
俺今ツイート先間違えてないか。
俺ツイート先間違えてないな。
ごめんなさい。
こっちじゃなくてこっちですね。
こっちにツイートしてOK。
じゃあやってみましょう。
ケントさんです。おはようございます。
日曜日からご参加いただきありがとうございます。
スマホからやってるのでツイート先がサブ赤の方に行っちゃいましたね。
本赤の方に流しなかったので今流しました。
じゃあやっていきましょう。
なぜ我々Unit-Sをかけないのかっていうところですね。
目次的には初めにUnit-Sの壁とその乗り越え方、
メンタルの問題、コストの問題、知識経験の問題、最後終わりにというところの流れだそうです。
では行きましょう。
初めにですね。
こんにちは。
ユニットE2Eテストの児童化を生業にしている石井さんと申します。
ユニットテストに限らず何かを始めようと思った時、人は様々な壁に直面しますよねと。
知識経験の問題、コストの問題、コストは金銭とか時間とかホゲホゲみたいですね。
メンタルの問題、納得感であったり不安感であったりとか。
それらが複合的に結びつく社内政治的な問題などなどですね。
そしてそれらの壁を乗り越えて第一歩を踏み出すことには大変な困難を伴いますと。
この記事ではユニットテストを確認にあたって、どのような壁、問題があるのかを確認して、
それに対してどのようなアプローチをすれば乗り越えられるかというのを考えていこうかなというふうに思っておりますということでした。
03:01
はい。
というところですね。
じゃあ早速いきたいと思いますけれども。
はい。
Kさんですね。
おはようございます。
ご参加いただきありがとうございます。
お日曜日の朝1から来ていただくとは思えなかった。
はい。
というところですね。
タイトルの通りです。
前者の記事は日本語の記事ですね。
シフトさんの書かれた2021年の記事なのでちょっと古いですけど、すごく参考になりそうだったので読んでいこうかなと思います。
後半、後者の方はクラウドフレアワーカーズのブログですね。
はい、いきます。
一つ目ですね。
ユニットテストの壁とその乗り越え方です。
まずメンタルの問題からですね。
はい。
もともとこんな話から始まるんですけど、根本的にまずモチベーションが上がらないと。
はい。
というのがあります。
それはユニットテストのメリットとか魅力に理解とか納得がいけないからですね。
頭で理解してもぶっちゃけ心が納得しないのでやっぱりモチベーションが上がらないなという意見もあるというところですね。
人間はやっぱり無駄なことをやりたいとはなかなか思えません。
仮に無駄と思いながらやったとしても、大抵本質的なところを見逃しているので、価値のないアウトプットはしか出てこなかったりします。
ということで無理にやる必要も、無理にモチベーションを上げる必要もありません。
最初にやるべきことはユニットテストのメリットとか魅力を知り納得することです。
まずは焦らずユニットテストのことを知ってあげましょうというところでした。
はい。
まあそうですね。
まあでも、そうかもしれないなあ。
まあ仕事だからと言って割り切ってやる分には別にいいし、それでやれるのであればそれはそれで僕はいいと思いますけど、
やっぱりモチベーションがあった方がそれはもちろんいいと思いますよね。
はい。
少なくとも納得感がないままやったところでストレスも溜まりますしね。
プラストレーションも溜まってしまうので、まあそれは確かにいいと思うので、
まずはユニットテストというそのものを知っていくのは本当にいいアプローチだと僕は思いましたね。
なるほどでした。
はい。
ただ一点だけ気になったというか、
重爆の隅につかせていただくと、
人間無駄なことをやりたいとはなかなか思いませんと言いますけど、
まあ無駄の定義が人によってとコンテキストによってまちまちですし、
まあそれで言うと極論じゃゲームだって無駄だし、
僕のこの配信すら無駄じゃないのって言われたら、
まあそういう目線をする人もいるので、
まあ無駄の定義が難しいから、
なかなかやりたいとは思えませんって断言するのは難しいなとちょっと思っちゃいましたっていう、
本当に重爆の隅ですね。
はい。失礼しました。
では行きましょう。
でも人間には無駄は必要だと思いますよ。
無駄があるし、そういうところから余白とは余裕が生まれるので、
無駄は無駄ではないんだよねっていうのが最近思うところだったりします。
はい。
では戻りますね。
で、続いての、えーなんだっけ。
このメンタルの問題ですね。
えー続いて、モチベーションはあるんだけど、
いろんな理由をつけて逃げてしまうっていうところですね。
はははは。
できないじゃなくて、逃げちゃうってところですね。
はい。趣味で実装するのともかく、
実装する場合は使える時間が限られています。
その上、ユニットテストがなくてもプロタクトが動くし、
手動で動作確認するなどの、まあ勘弁で分かりやすい代替手段まであります。
はい。その通りだなと思いました。
この状況で知識のない分野に手を出すリスクを取れる人がどれだけいるでしょうか。
まあそうそういないですよね。半号。
まあそうね。
なのでユニットテストをやったことがない人が、
仕事で急にユニットテストをやれと言われても理解できない。
06:01
できないのは当然ですと。
ユニットテストは作った本人がやるのが原則と言われていますが、
最初期の導入に限って言えばそれは嘘です。
ユニットテストを分かる人にサンプルを作ってもらって、
ユニットテスト専属のエンジニアを一人立てて、先駆者として道を切り開いてもらう。
そういった戦略を立てて取り組んでいきましょうと。
少しのことにも、選脱は荒間方式ごとなりというやつですかね。
はい。違うかもしれないですけどというふうにおっしゃってますけど。
まあまあまあそんな感じはしますね。
本当最初期の導入は、確かに知見持っている人、経験持っている人が
最初にユニットテストを書く方が多分いいと思いますね。
全く持ってそういう人がいないのであれば仕方ない感はありますし、
その組織全体として今から導入し始めるというところでいいと思います。
ただ、もし余裕とかお金があるんだったらそれでも外部の人とか技術顧問的な人を
外から招聘してレビューしてもらうのがいいんじゃないかと思いますね。
それだけでもテストの文化っていうのはなかなか根付きづらいし、
導入も難しいかもしれないですね。本当最初期は。
なのでその第三者を招聘するのは全然アリな話だと思います。
ビジネス的にもいいと思いますけどね。
ある程度経験値ができたならば一人でそれぞれのプロジェクトで書き始めてもいいと思います。
続いて、今のがメンタルの問題ですね。続いてコストの問題です。
そもそもユニットテストを書く時間が見積もらえていない。
本当にどうしようもない問題ですね。
ユニットテストはなんだかんだ書くのに結構時間がかかります。
その上メンテナンス負荷も侮れないです。
きちんと書く場合は最低でも書かない場合の2倍は見積もってほしいと言ってます。
まあ経験値的に僕も近いかな。何やかんやそれぐらいかかります。
とはいえそこまでの時間を確保するのはなかなか難しいです。
そういう時はユニットテスト専門の人を立てて、
その人だけは集中的に頑張れるようにコースを区面するとか、
全体的に少し多めに見積もって最初はメリットの教授を諦め、
メンタルの問題を解消するまで練習時間を設けると。
本当に大事なわずかな箇所だけユニットテストを実装するなどすると良いかと思います。
それすら難しいと思う場合は、
根本的にユニットテストのメリットへの納得感まで足りないか、
あるいはプロジェクトの現状に限りなくミスマッチだと思います。
ユニットテストはあらゆるシチュエーションで万能に機能する技の段階ではありません。
プロジェクトの動向を観察し、やっぱ必要だなと思った段階で導入するのも選択肢の一つです。
ただしユニットテストを未経験者ばかり集まっている場合は、
今から始めますと言っても始められるものでもありません。
準備期間も必要だという点には十分ご留意くださいということでした。
ぐうのでも出ないぐらいそうだなと思っちゃいましたね。
長期目線で考えるとビジネス的にはユニットテストを導入するのは素晴らしいことだと思うので、
僕は導入してほしいし、
しっかり見積もりするときもテストの構図は見積もりたいなと思います。
あとはテスト項目書とかを外部に委託して、
人間がテストするようなドキュメントを作って、
それに対してポチポチやっていくのも別にいいと思うんですけど、
人そのものもミスをする可能性が多いので、
09:01
ユニットテストでカバーできて機械が自動的にやって、
なおかつスピーディーにやってもらえるんだったら、
それに越したことはないんじゃないかと思ったりもします。
とはいえ、ユニットテストを書くにしても書く人がやっぱり人間なので、
人間っていうことはミスがするということは、
漏れる可能性もあるし考慮が足りなかったみたいなのもあったりしますし、
いろんなケースが、ヒューマンエラーはあり得るんですよ。
なのでユニットテストに全部倒すというか、
ユニットテストだけで担保するっていうのもまた違うと思ってて、
いわゆるモンキーテストですね。
その場で適当に使ってもらうみたいなテストも必要だと思います。
両方いられるのが理想的なんじゃないかなと思いますね。
絵として本当のユーザーは、僕らが開発者が想像しえない使い方とか、
そんなパターンあるんよみたいなことを使い方で全然してくるので、
そういうのも含めてユニットテストだけで全部担保してますね。
また違う気はしました。
はい、そんな感じです。
続いて経験とか知識の問題ですね。
ユニットテストのメリディをきちんと理解できておらず、期待が高すぎるようと言ってます。
とりあえず理想的な実装でやればメリットを得られるでしょうと。
ホワイトボックスで実施して、カバレッジはC2ですね。
条件網羅を100%。TDDってやるぜみたいな。
まあまあ無茶ですねって書かれてますけど、まあ無茶ですね。
ユニットテストといえばTDDといった印象は確かにありますけども、
TDDはあくまで開発技法の一つでしかないです。
TDDをやっていなかったとしても、リファクタリング時の心理的安全性の確保、
リグレッションテストの高速化といったテストとしての価値は十分あります。
無理してTDDにこだわって開発者に心理的不安感を与えることにメリットは全くありません。
断言されましたね、すごいな。
こだわりすぎるのやめましょう。
とはいえTDD、もしくはBDD、ATDDですね。
ATDDってなんだ?ちょっと僕分かんないですね。
TDDは、えーなんだっけ。やばい。
えーやばい。TDDなんだっけ。テスティング。
あーやばいやばい。やばい、ほんとにひどいな。
テストドリブンデベロップメントですね。はい、失礼。
BDDは、ビヘイビアドリブンデベロップメントですね。
そういうテスティングフレームワークもあります。BDDと言われるものですね。
いわゆる本当に振る舞いにフォーカスを置いたテストの書き方をするフレームワークというのがあります。
日本の有名なBDDってなんだっけ。空手ってものがありますね。
っていうのがあって、軽く見たんですけど結構面白かったですね。
結局確かにJavaベースだった気がするんですけど、
今まで書いたことのないテストの書き方をしててすごく面白いし、
人間に沿った書き方ができて面白いなと思いました。BDDってのもあります。
ATDDはすいません、僕がずっと存じ上げてないんで、これは不勉強で申し訳ないです。
とはいえばいろんなテストの書き方のフレームワークとか手法はあります。
それぞれには設計をより深く考えさせるという捨てがたいメリットもあります。
挑戦できるならぜひ挑戦してください。
ATDDに限らないんですけど、始めるコツは完璧にこだわらないことです。
メリットはメソッドの規模や重要度は気にせず、まずは分かっている要件をちょろっと書き出して、
12:01
それをNGからOKに変えるところから始めましょうと言ってます。
どんなときもまずはスモールスタートからしてくださいということですね。
ホワイトボックスやカバレッジにこだわるのもやめましょう。
こだわりすぎると手段と目的が入れ替わってしまうからです。
これ本当に大事な一言ですね。
こだわりすぎると誰のためのというか、何のためのというのがまた入れ替わってきてしまうので、
これ本当に重要です。
大事な機能や動作をきちっとテスト、ブラックボックステストをしたら、
あとのカバレッジはただの指標です。
なぜカバレッジが大きく上がったのか、実装漏れがあるかもというところもありますし、
なぜ下がったのか、実は全然検証していなかったところがあるのかもみたいなところですね。
これを振り返るための目安でしかないです。
カバレッジはあくまで指標です。
100%だから良い、80%だから良いではなく、
どう変化してそれがなぜなのかというのを大事にしましょうと言っています。
はい、いやもう、はい、はい、はいしか言えなかった。
はい、では続いて。
手をつけたけど普通にわからん。
何か違う気がする。
効果は出ない。
みたいなこともあるようでいますね。
まず手をつけられた時点であなたは素晴らしいです。
一番大きな壁を乗り越えられたと言っても囲んではないです。
まあ何か言いますよね。
目標に対して着手し始めたり、
第一歩を踏み込んだらもう半分越えたよっていう格言が確かあった気がします。
半分だったり9割だったりみたいな色んな意見がありますけど、
一番の壁はその第一歩を踏み出すところがやっぱり一番の壁だそうです。
だいたいどんな世界でも同じだと思いますけど。
はい、なのでこれを越えられたというので素晴らしいと言っています。
ただ残念ながらユニットテストっていうのはあらゆるソースコードをテストできるわけでもありません。
テストしやすいもの、しにくいもの、
テストしてもあまり意味のないものもあれば、
テストしにくいけど重要だからテストすべきものもあります。
あまり深いことを考え始めると手が止まってしまうので、
まずはできるところからやってみましょう。
ユニットテストの実装に慣れてきたな、
書くことに抵抗感なくなってきたなと思うようになったらステップアップしましょう。
例えばAzureなどでインテリティブな開発を行っている場合は、
その後の手動テストで検知された不具合を見て、
どこをテストしたらよかったのか振り返ってみましょう。
そしてその箇所について実装するなどの積み重ねをしてみるとよいでしょう。
テストのための技がそもそもわからないという場合は、
Legacy Code改善ガイドなどの書籍を渡ってみるのもいいですし、
インターネットでスタブやオーバーライド、
メソッドの切り出しなどを検索するとそれなりに情報も出てくると思います。
あるいはテスト技法や後続のテストの積み分けといったテストそのものに対する知識・経験が足りない場合もあります。
もしQAチームが案件にいる場合は、
ペアプロ的に単体テストをやってみるとよいでしょう。
いない場合はチームから何人か、チームの規模によりますけど、
QA専属のメンバーとして働いてもらってペアプロをするのも良いと思います。
この時、たとえ知識レベルに差があったとしても、双方がリスペクトを持ち、
対等な関係になるように注意をしてください。
これがすごく重要ですよと言っています。
教えてもらうからその人が上というわけではないですし、
逆に襲われるんだから僕が下だというふうに思う必要もないということですね。
15:01
はい、というところです。
なお、フロントエンドのユニットテストは、
ユニットテストという名のほぼ結合テストです。
なるほど。
事前準備的な処理が結構ありすごく大変です。
これは本当そう思います。
いわゆるユーティリズとかフックスとかに切り出したものだけであれば、
単体テストは楽勝なんですけど、
それだけでもちろんフロントエンドのテストとしては十分じゃないと分かれているので、
そうなんですよ。準備がすごい大変なんですよ。
もしバックエンドより先にフロントエンドに挑戦しようとしているのであれば、
それはおそらく死での旅になります。
僕、バックエンドのテストから入ったのですごく共感はあるんですけど、
ここまで言葉を使うということは、
まずフロントからやるのはやめとけよということですね。
書いてました。
初めての挑戦としては難しすぎるので、
まずはバックエンドから挑戦しましょうというところです。
以上、いろいろ書いてきましたけど終わりにというところですね。
今回の記事ではあまり体系的にユニットテストの魅力については書きませんでしたので、
ひょっとするとそんなに苦労してもユニットテストやる必要がなくないと思われた方もいらっしゃるかもしれません。
確かにユニットテストの実装にはここまでに書いたように多くの壁が存在します。
必要なものだけを挙げても、まずユニットテストができるだけの適切なコーティング力、
テストフレームワークの理解といったユニットテスト特有の開発知識が必要になります。
チームが置かれた状況に応じて、
適切なテストの戦略、テスト設計の知見といった完全にテストよりの知見も必要になります。
また、それらを行うだけの時間、計画とそれらをやり遂げるという自信も必要になってきます。
ですが、それらの壁を乗り越えられたときに得られるメリットをまたはかり知れないものになります。
不具合の早期検知、システム回収時の機能補償、それによる心理的安全性の確保、
ユニットテスト設計の複次的効果による実装の最高レビュー機会の獲得、
ユニットテスト実装の複次的効果によるテッタブル、複雑でなく再利用性が高いみたいなソースの実装、
テストレポート出力による使用や実装状況の可視化などなど、
本当に得られるメリットは膨大にあります。
幸い、テストコードはソースをうまくテストできないことはあっても、ソースを壊すことはまずありません。
リファクタリングとか始めなければ、という条件はあります。
恐れず、面倒くさがらず、ぜひともチャレンジしてみていただけると嬉しく思います。
長い文章を読みいただきありがとうございました。
シフト社の方は株式会社シフトさんですね。
テスト専門にされている、ソフトウェアテスト専門の会社シフトさんですね。
実務経験5年で、シフトに入社から2年半が経過した時に書かれたブログです。
これが1年ちょっと前のブログなんですけどね。
というところでした。
なかなか面白かったですね、本当に。
テストを書いたことある方は、みんなうんうんそうだな、わかるみたいなことになるような気はしています。
それぐらい壁は大きいんですけど、やっぱり得られるメリットが大きいのも本当に全く同意なんですよね。
なのでぜひぜひ書いてみていただければなと思いますし。
難しかったら、やっぱり有名なフレームワークですね。
世間一般で流行っていると言われている、まずユニットテストのフレームワーク、たくさんあるんですけど。
18:05
今のところジェストでほぼほぼ一挙なんじゃないかなっていうぐらいには、
確かまだジェストが強い、ダウンロード数が1位だった記憶がありますので。
1ヶ月のジェストのチュートリアルも確かあったと思うので、
その辺で手を動かしてみて、こうやって書くんだなっていうのを知っていただくのがまずはいいんじゃないかなと思ったりしました。
いろんな使い方があります。
スタブの話もありまして、スパイすることもできたりしますし。
いろんな機能もありますのでね。
カバレッジ出力することもできたりしますので、ぜひぜひ触ってみていただければいいんじゃないかなと思ったりしていました。
以上が前半の記事ですね。
なぜ我々はユニットテストが限らないのかというところからでした。
残り時間、あと7分ぐらいしかないんですけど、もう1個ですね。
How the Cache Worksですね。
クラウドクレアワーカーズのブログの1つ、How the Cache Worksを読んでいくと思います。
以前、How Workers Worksってところですね。
どうやってワーカーズが動いているのかというところを見させていただいたんですけど。
それもすごく面白かったので見てみてください。
もう1個今日は別のやつで、Cacheがどうやって動いているのかというところを見ていこうと思います。
多分時間オーバーするので途中で切っちゃうかもしれないし、時間オーバーして読み切っちゃうかもしれないです。
その時の僕の気分に任せます。
7分後の自分が判断します。
はい、じゃあ行きましょう。
ワーカーズっていうのはクラウドクレアのエッジネットワーク上に設計構築され、
開発者がクラウドクレアのCacheと直接やり取りできるようにしました。
Cacheっていうのは静的または動的コンテンツに頻繁にアクセスするための便利な方法として、
一時的なデータセンターやローカルのストレージを提供することができます。
開発者がCacheに書き込めるようにすることで、
ワーカーズはクラウドクレアのCDN上でCacheの動作をカスタマイズする方法を提供します。
Cacheの利点についてはもちろん、
ラーニングセンターのWhat is Cachingの記事があるのでそこを見てみてくださいと別のリンクが貼られてますね。
クラウドクレアワーカーズはCacheの前でも後でも実行できるので、
ワーカーズを利用してCacheから返されたアセットを修正して、
レスポンスに署名したりパーソナライズすることもできますよと言ってます。
そこまでいけるんだ。
なるほど。
高機能だな。
じゃあ入っていきましょう。
インタラクティングウィズ・ザ・クラウドクレア・キャッシュですね。
クラウドクレア・キャッシュとのインタラクションのところですね。
概念的にはワーカーを使用して、
クラウドクレアのキャッシュと対話する方法が2つありますよと言ってます。
大きく分けて2つでいいですね。
1つ目ですけども、
ワーカーズスクリプトでフェッチを呼び出しましょうと。
クラウドクレア経由でプロキシされたリクエストっていうのは、
ワーカーがなくてもゾーンのデフォルトまたは設定された動作に従ってキャッシュされます。
例えば.jpgで終わるファイルなどは静的アセットはデフォルトでキャッシュされますよとか。
というところですね。
ワーカーズはこの動作をさらに簡単にすることもできたりしますよと言ってます。
へー、なるほど。
21:00
続いてもう1個のほうですね。
クラウドクレアのキャッシュルールを設定する。
つまりリクエストのcfオブジェクトで操作するっていうのが2つ目の方法ですと言ってますね。
ワーカーズスクリプトっていうのからキャッシュAPIを使用してレスポンスを保存する。
これによりオリジンから来たのではないレスポンスをキャッシュすることができて、
以下のような細かい制御も可能になりますと。
2つありますね。
cache.putというメソッドがあって、それに渡されるレスポンスにキャッシュコントロールなどのヘッダーを設定することができます。
なるほどね。
あらゆるアセットのキャッシュ動作をカスタマイズすることができます。
もう1つが、ワーカー自身が生成したレスポンスをキャッシュ.putでキャッシュすることができます。
ワーカーが作ったレスポンスをそもそもキャッシュしちゃうということですね。
結構、cdnをガリガリに設定できたりコントロールできるんですね。
これはクラウドフレアワーカーだけかわからないです。
僕はあんまり他のcdnのサービスをガリガリに触ったことはないんですよね。
一応、ファストリーさんだけ軽く触ったことはあるんですけど、
ファストリーって固有の言語みたいなのがあるじゃないですか。
あれをガリガリに学んで書いたことは実はあんまりないんですよね。
他のcdnと言うと、結局クラウドファンとか、AWSクラウドファンとかぐらいしか触ったことがないので、
こんなガッツリ設定までやったことはなく、
でもそれが逆にできてしまうクラウドフレアワーカーっていうのは、
やっぱり魅力的だと感じてきましたね。
続いて、Paging Assets Stored with the Cache APIですね。
キャッシュAPIで保存されたアセットのパージってところです。
キャッシュAPIの操作によってキャッシュに保存されたアセットっていうのは、
いくつかの方法でパージすることができます。
ワーカー内でcache.deleteっていうのを呼び出して、
一数のリクエスト変数を持つアセットのキャッシュを無効にします。
これが一つ目でした。
cache.deleteっていうのをワーカー内で呼び出すことができるんですね、そもそも。
一致するリクエスト変数を持つアセットのキャッシュを無効にします。
この方法でパージされたアセットっていうのは、
ワーカーランタイムが実行されたデータセンターに対してのみローカルにパージされます。
アセットをグローバルにパージするには、標準のキャッシュパージオプションを持つ必要もあります。
使用する必要があります。
キャッシュAPIの実装に基づき、すべてのキャッシュパージエンドポイントが、
キャッシュAPIによって保存されたアセットをパージするために機能するわけではないですよ、
というところに注意してくださいということでした。
はいはいはい。なるほどね。
なるほど。
パージエンドポイントっていうんだから、それができると思ったけど、
すべてそうだというわけではないわけですね。
もしくはそれ専門のための機能というわけでもないよ、
というところに注意が必要です。
この辺は多分ドキュメントのみで使い方をしっかり学ぶのがまずはいいんじゃないかというところですね。
続いて、
ゾーン上の全てのアセットというのは、
パージエブリシングキャッシュオペレーションを使用してパージすることができます。
えー、何ですかそれは、
パージエブリシングキャッシュっていうオペレーションがあって、
それを使用することでパージすることができますと言ってますね。
へー、そんなのあるんや。
24:01
このパージというのは、
メソッドセットに関係なく、
すべてのデータセンターでクラウドフレア・ゾーンに関連するすべてのアセットをキャッシュから削除します。
ほう。
名前通りですね、パージエブリシングキャッシュですね。
エブリッシングカスタマーズ、違うエンタープライズ カスタマーズでした、失礼しました。
エンタープライズカスタマーズでは、ワーカーで response.headers.appendというメソッドがあるので、
それを呼び出し、そのリクエストにcacheタグっていう、 cache-tagですね。
っていう値を動的に追加することで、 cache tagsをリクエストに追加することができます。
動的に追加できるんですね。
一度設定されると、これらのタグはゾーン上の 全てのキャッシュされた資産を無効にすることなく、
キャッシュから選択的に資産を パージするために使用することになります。
応報をコントロールできるってことですね。
パージに対してもすごいコントローラブルに 扱うことができるってことでした。
いや、なかなか魅力だな、やっぱり。
続いて、Edge vs Browser Cachingですね。
Edgeとブラウザーキャッシュの比較ってところですね。
ブラウザーキャッシュっていうのは、クライアントへの レスポンスで送信されるキャッシュコントロールヘッダー。
event.respondwithというメソッドに渡される、 または約束されたっていうのがあれか。
プロミスですね。
約束されたレスポンスを通じてキャッシュコントロール ヘッダーを通じてマイウェア制御されますと。
ワーカーはレスポンスにこのヘッダーを設定することで、 ブラウザーキャッシュの動作をカスタマイズすることができます。
このドキュメントでは触れてないですけど、
クラウドフレアのキャッシュを制御する 他の手段には以下のものがあります。
ページルールとクラウドフレアキャッシュの 設定文字というものがあります。
そのページのリンクもあるので見てみてください。
もしJavaScriptを書かずにコントロールしたい場合は、
How to Control Cloudflare's Cache Support っていう記事がありますので、
そこを見てみてくださいということでした。
なるほど。
で、ちょっと補足的なのがありますね。
クラウドフレアのオブジェクトをキャッシュするには、
キャッシュAPIとフェッチのどちらを使うべきですかと。
フェッチAPIもあるからそうですね。
ワーカーズがミドルウェアとして動作する、
つまりワーカーがフェッチ経由でサブリクエストを送信するリクエストでは、
フェッチを使用することが推奨されます。
これは意図しない動的キャッシュを防ぎつつ、
キャッシュを最適化するための既存の設定があるためになります。
バックエンドがない、つまりワーカーズサイズのように、
プロジェクト全体がワーカーズ上にあるプロジェクトの場合は、
キャッシュをカスタマイズするには、
キャッシュAPIが唯一の選択肢になります。
アセットはワーカーのサブリクエストで指定されたホスト名でキャッシュされます。
サブリクエストで指定されたホスト名でキャッシュされます。
ワーカー自身のホスト名ではありません。
リクエストと時の名前でキャッシュされるんですね。
これはちょっと落とし穴感がありますね。
したがってキャッシュされたアセットを削除するには、
ワーカーサブリクエストに含まれるホスト名に対して削除を実行する必要があります。
27:00
なるほどですね。
てことはフェッチを使うときはそこの名前をしっかり注意してください。
しっかりアプリケーションの方で管理しないといけないなというところですね。
なるほどね。
でもそういう名前は最終的にコンスタンスみたいなファイルにまとめると思うので、
そこで一元管理しておけばとりあえずは大丈夫かな。
ただサブリクエストごとに切られますし、
その名前で保存されるのでそれに対して削除するしかないですよということですね。
あとはアプリケーションそのものがないというか、
バックエンドがないアプリケーションですね。
全部ワーカーズ上にあるものですね。
ワーカーズサイツっていうようなホスティングサービスがあったと思うんですけど、
それの場合はキャッシュをカスタマイズするにはキャッシュAPIしかないよということだけ注意が必要ですよということでした。
時間が続いたら32分になったんですけど、
日曜日ですしこのまま走り倒したいと思いました。
今ちょうど出てきたフェッチとキャッシュAPIの比較みたいなところに入ったんですけど、
そのフェッチとキャッシュAPIの説明がこの後に続くので、
やっぱりそこまで読まないとふーんって終わっちゃう気がするんで、
本当にあともう少しなんで、
多分10分もいかないくらいですかね。
読んでいきたいと思います。
じゃあフェッチの方ですね。
まずフェッチの方からです。
ワーカーズのコンテキストでは、
ランタイムが提供するフェッチはクラウドプレイヤーのキャッシュと通信をしますと。
まずフェッチはURLが別のゾーンにマッチするかどうか確認します。
もしマッチすればそのゾーンのキャッシュまたはワーカーを通して読み込みをしますと。
そうでない場合はURLがクラウドプレイヤー以外のサイトであっても、
自分のゾーンのキャッシュをまず読みに行きます。
フェッチのキャッシュ設定っていうのはクラウドプレイヤーの設定に基づいて自動的にキャッシュルールを適用します。
フェッチではキャッシュに到達する前にオブジェクトを修正または検査することはできませんが、
キャッシュの方法を修正することは可能ですと言っています。
なるべくエラーパターンというか正常系じゃないパターンについても
なるべくデフォルト値をサポートしてはいますよねってところも結構注目だなと思いました。
レスポンスがキャッシュを満たすと、
レスポンスヘッダーにはCFキャッシュステータスのヒットっていうのを含みますという風に書いてますね。
CFキャッシュステータスを見ればオブジェクトがキャッシュされようとしていることが分かります。
ちゃんとヘッダーを見てみてくださいということですね。
これはクラウドフレアの独自のレスポンスヘッダーだと思いますね。
CFっていうのがクラウドフレアの略かな、CFっていうのが。
CF-キャッシュ-ステータスコロンヒットっていうのと
CF-キャッシュ-ステータスっていうのがあるのでその辺を見てみてくださいということでした。
このテンプレートではフェッジを使用して特定のリクエストに対する
クラウドフレアキャッシュの動作をカスタマイズする方法も示してますよっていうことでした。
このテンプレートのテンプレートっていうところに記事のリンクがあって
これもまたクラウドフレアのワーカーズブログの一つですね。
その中にexamplesっていうページがあるのでそこの中に
そのテンプレートがあるので見てみてくださいってことでした。
じゃあもう一個ですね、キャッシュAPIの方です。
キャッシュAPIのとこまで見ていきます。
これでラストですね。
じゃあキャッシュAPIですけども、キャッシュAPIっていうのはリクエストオブジェクト。
30:02
具体的にはリクエストURLがキーでレスポンスが与えとなる
エフェメラルキーバリューストアと考えることができます。
エフェメラルっていう単語を僕は初めて聞きましたね。
まあとりあえずリクエストのURLとレスポンスが与えという
キーバリュー型のストアという風に考えることもできますよという風に言ってますね。
クラウドフレアキャッシュでは2種類のキャッシュ名前空間というのが
利用できますよと言ってます。
キャッシーズ.デフォルトともう1個はキャッシーズ.オープン
オープンの方はメソッドですね。
という2つがあります。
キャッシーズ.デフォルトっていうのは
このキャッシーズ.デフォルトにアクセスすることで
デフォルトキャッシュ、フェッチリクエストで共有される同じキャッシュですね。
にアクセスすることができます。
これはレスポンスを受け取った後すでにキャッシュされているコンテンツを
上書きする必要がある場合にとても便利ですよと言ってます。
もう1個キャッシーズ.オープンメソッドです。
こっちはレットスペースキャッシュイコール
アウェイトのキャッシーズ.オープンというような
メソッドを実行するみたいな感じですね。
引数にはキャッシュネームみたいなものを使用して
定数で持ったり文字列で渡しますと。
これを使用すると名前空間キャッシュですね。
フェッチリクエストで共有されるキャッシュとは別のものになりますと。
にアクセスすることができます。
それとは別の名前空間がちゃんと切られているので
そこにアクセスすることができますと。
キャッシーズ.オープンはキャッシーズ.とデフォルトが異なり
非同期関数であることに注意してくださいということです。
デフォルトの方はオープンの方は関数で
かつこれは非同期関数なのでちゃんとアウェイトしてくださいね
ということでした。
逆に言うとコールするときはちゃんと非同期関数なので
Async関数の中に入れなきゃいけないのかな
というところがありますね。
キャッシーズ、キャッシーAPIを使用する場合は
この辺注意してくださいということでした。
プログラムでキャッシュの保存や削除を
交代したい場合があるでしょう。
例えばあるオリジンがキャッシュコントロール
MaxEdge0みたいなヘッダーで応答していて
変更できないものとします。
代わりにレスポンスを複製して
ヘッダーをMaxEdge3600の値に調整をして
キャッシーAPIを使用して変更したレスポンスを
1時間保存することもできますと。
はーなるほどね。
リクエストはもうどうしようもならないので
レスポンスのところにハッキングをして
そこで複製をしておいて
ヘッダーを設定して
ワークアウトの方で持つことができるよ
ということができます。
いやーこれありがたいな。
キャッシーAPIすごいですね。
まぁまぁそんなテクニカルな状況になるか
っていうのはまた難しいですけど
なんやかんや必要になる気はしてるんですよ。
はい。
フェッチリクエストに頼らず
キャッシュからレスポンスにプログラム的に
アクセスしたい場合もあるでしょう。
例えばhttps://example.com
スローレスポンスみたいな
エンドポイントに対応するレスポンスが
すでにキャッシュされているかどうか
確認することができますよと言ってます。
もしそうならば遅いリクエストを避けることも
できますよね。
スローレスポンスっていうのは面白いですね。
というエンドポイント。
33:01
エンドポイントのレスポンスが遅い場合ですね。
という場合はそもそも
キャッシュされているかどうかっていうのを
まず確認してそうならば避けることも
できますよって言ってますね。
なるほどね。
この点
リクエストがどうやって判定をするのか
どこでコントロールするのか
ちょっとまだ書いてないので
この辺は他のブログ記事を読まなきゃいけない
気がしますね。
そこができるというのは結構大きいですね。
選択肢としてあるというのは。
こちらのテンプレートはキャッシュAPIの使用方法を
示してますので
キャッシュAPIの制限については
制限事項っていう章もあります。
リミッツっていうページもあるので
そこを見てみてくださいと。
もちろんこちらに対しても
Appleの中にキャッシュAPIっていうテンプレートがあるので
そこも見てみてくださいっていうことでした。
以上クラウドフレアワーカーズの
How the Cache Worksのところも
見ていきました。
ちょっと時間オーバーしたんですけど
今日の朝方はこちらで以上にしたいかなと思います。
最近の
LDSlideで
僕はクラウドフレアに
完全に魅了されてしまったので
今ちょいちょい見始めたってところなんですけど
かなり
クラウドフレアワーカーズのエッジサーバーでできることが
すごく魅力で
ノードJSアプリケーションが動くと
もちろんメモリーとかの限界はあるんですけど
それでもノードサーバーとして
動いちゃうっていうところが
めちゃめちゃ怖いというかすごいと思いました。
それにSQLiteまで入ってくれちゃってるので
本当にアプリケーションとして動いちゃうんですよね。
っていうところがかなり魅力だと僕は思ってて
今クラウドフレアワーカーズを
見てるって感じでした。
今後また読むときに
時間が余ったらちょいちょい読んでいこうかなと思ったりしてますので
お付き合いいただけたら
今日は今日の朝活動は以上にしたいなと思います。
日曜日の朝から
こんなに参加いただきありがとうございます。
みなさんすごい勤勉な方ですね。
いいリズムだなと思いました。
ということでまた明日も
ゆっくりのんびり何か記事読んでいきたいと思います。
では今日は日曜日ですね。
休日のんびりとお過ごしいただければなと思います。
では終了します。
おつかれさまでした。
