00:05
はい、えー、9月20、え、違う、6月ですね。
5月20日、月曜日。
じゃあ、僕は朝9時を回りました。
本日は東京もいい感じの晴れの天気ですね。
ちょっと気温があったかいですけど、皆さんいつから過ごしているでしょうか。
じゃあ、本日も、えー、始めていきたいと思います。
おはようございます。ゆめみのキースことくわはらです。
本日も朝活を始めていきたいと思います。
えー、で、どうですね、前回、えーと、
まあ、途中まで読んだんですけど、えーと、
ファーストパーティークッキーレシピっていう記事ですね。
読んでたんで、まあ、それの続きも読んでいこうかなと思います。
で、残り時間、えーと、JSのメディアタイプと、あの、RFC9239という記事があって、
まあ、ちょっとそれ気になってるので、そこもちょっと読んでいこうかなと思います。
はい、じゃあ、えっと、昨日に引き続きまして、
えーと、読んでいくんですけども、
えー、今回は、ファーストパーティークッキーレシピ4サイズ、
えー、withサブドメインズっていうところから、えーと、書いていこうかなと思いますね。
はい、えー、じゃあ、いつも通り読んでいきまーす。
よいしょ、ほい。
えーとですね、いきますと、
はい、サブドメインを持つサイトで、まあ、それらすべてで1つのセッションを持ちたい場合、
えー、ホストセット時ってのはちょっと制限が多すぎる可能性がありますと。
えー、例えば、えー、ニュースサイトには、えー、
ファイナンス.ニュース.サイトみたいなものとか、
まあ、スポーツ.ニュース.サイトなどのトピック用の、まあ、サブドメインがあってですね、
まあ、それらすべてで1つの、えー、ユーザーセッションを使いたい場合にありますと。
まあ、このような場合には、その、アンスコアンスコホストの代わりに、
えー、アンスコアンスコセキュアセット時っていうのを使用して、まあ、ドメインをし、えー、しますと。
はい。で、まあ、今回のその、えーと、
なんだっけ、ベストプラクティスのレシピっていうのは、
えー、まず最初ですね、セット-クッキー-コロンで、
えー、アンスコアンスコセキュア-クッキー-ネーム、
イコール、えー、クッキー-バリューっていう値を指定しますと。
で、続いて、えーと、セキュアっていうのをつけて、
あとは次ですね、ドメインイコールニュース.サイトみたいな、まあ、サブドメインのドメインを指定しておきますと。
で、えー、パスワーキーのと同じですね、イコールスラッシュにしておくのと、
まあ、HDDBオンリーで、えー、マックスエイジはとりあえず、えー、777万6千、まあ、あの、90日ですね。
で、あとは、セームサイト-ラックスっていうところですね。
にしておきましょうというところでした。
はい。で、まあ、一個一個また、あの、ディテールを見ていこうと思いますが、
はい、あ、今回のディテールは結構短いですね。
まあ、前回のディテールと結構重複するところがあるからだと思います。
はい。まあ、前回と違うのは、その、セットクッキーとセキュアの2点ですね。
それ以外は前回の、えーと、レシピと全く同じ内容ですね。
あ、てか、セキュアも前回つけてるから、もうほんと全く一緒で、ほんとセットクッキーのところだけしか値変わってないですね。
ほい、あ、てのどさんですね。おはようございまーす。ご参加いただきありがとうございます。
はい、まあ、昨日について、The First Party Cookie Recipeっていう記事と、
はい、ま、あの、JSのメディアタイプのRC-9239っていうのがちょっと面白そうだったので、そこを見ていこうかなと思ってます。
はい、で、今日は、えー、First Party Cookie RecipeのFor Sites With Subdomainsってところから入ってます。
03:07
はい。で、えーと、じゃあいい、続き入っていきますか。
えーと、アンスコアンスコセキュアっていうのは、えー、オプションのプレフィックスで、えー、
アンスコアンスコホストよりも要求事項がちょっと少なく、
また、クッキーにセクション属性っていうの が、 según、セキュア属性っていうのが設定されていることだけを要求します、と。
で、えーセキュア属性っていうのはクッキーをhttps Protocolのみで送信するように制限します。
えー、セキュア属性っていうのはクッキーをhttps Protocolのみで送信するよう制限し、
えー、アンスコアンスコセキュア設定時っていうのは、コッキーがセキュア属性で設定されたかどうかっていうのをチェックして、
ま、そうじゃない場合は拒否するようにブラウザに頼みます、と。
これによって攻撃者がセキュア属性のない別のクッキーで安全なクッキーをお書きすることができるようになりますよと言ってますね
はい
そうすると別にサブのメインとか関係なしにセットクッキーのところはセキュア属性でもいい気がしますね
最近はフルHDPSサイトっていうのが結構増えてきているのでそれでもいいんじゃないかなという気がしましたね
はい
今回はこれぐらいしか書いてなかったので一旦次のセクションに入ろうと思いますね
はい
まさひらさんですねご参加いただきありがとうございます
タイトルにある記事をダラダラとたらたら読んでる感じですね
はい
続いてのセクションですがちょっと長いな
はい続いてはですねサードパーティーサイトから開始されたリクエストでのファーストパーティークッキーアクセスを制限するっていうところですね
はい
で説明なんですけど
SameSiteイコールラックスと設定されたクッキーっていうのはクロスサイトのサブクエリサブリクエストでは送信されることはないんですが
ユーザーが元のサイトに移動するとき例えば別のサイトからのリンクを辿ったりするときに送信されますと言ってますね
さらにクッキーへのアクセスを制限し
SameSiteイコールストリクトで第三者のウェブサイトから開始された要求とともにクッキーを送信することを禁することもできますと
これはパスワードの変更や購入など常に最初のナビゲーションの背後にある機能に関連するクッキーを持っている場合に便利ですよというふうに言ってました
なるほどでした
クロスサイトのサブリクエストですねでは送信されないけどリンクだったり戻ったりするときに見れますよって言ってますね
レシピの方ですけど基本的には一緒なんですけどセットクッキーのところがさっきはセキュア属性がセキュアっていうのがセットウォッチについたんですけど今回はホストに戻ってますね
セットクッキーをホストクッキーネームイコールクッキーバリューにしてあってセキュアをつけてパスイコールスラッシュも一緒
HTTPオンリーでマックスエイジも770万6千なので90日最後にSameSiteイコールストリクトになってますね
06:01
こういうレシピでしたというところですね
まあ一応こういう設定もありますよというところですねここに関しては特にディテール記事はなかったので
はいという感じでちょっと冒頭短かったかもしれないですけどファーストパーティークッキーレシピっていう記事はこれで以上になりますね
基本的に共通しているのはセキュアをつけるのとパスイコールスラッシュっていうのは同時ですね
基本的にはパスっていうのはイコールスラッシュにしておくのが良さそうです
これによってサイトの全URLというところをちゃんと見てくれたりするので個別にしたい場合は個別のものをつけるんですけど
基本的に何も理由がないんだったらパスはスラッシュにしていいと思います
HTTPオンリーのところもまあ僕もこれはこれでいいんじゃないかなと思いますけど要求に応じて書いてくださいって感じですね
マックスエイジが約90日になっていますけども90日かどうかっていうのはちょっと皆さんの方で議論したくって感じになりますね
一応最大で400日以下にしてほうがいいよっていうこの記事でやってるんですけど
まあ400日に設定することはあんまないと思いますね
基本的には1年最大でも1年間じゃないですかね
思いますけどクッキー自体をそこまで長く講じるかっていうのはまた別の議論があるので
90ってのは結構落としどころかなっていう感はありますね
特に理由がなければってことでした
で、セームサイトのところですねストリクトにすると確かにちょっと厳密性なところが問われるのでそれはそれでいいかもしれないですね
サブリクエストっていうところでは制限されてしまうのでまあされてしまうというか制限できるのでそれはそれでいいんじゃないかなと思います
で、リンクからの戻ったりとかユーザーが普通に辿っていくときには送信されるのでそれはそれでっていうところでありますけど
要はその第三者からのウェブサイトのリクエストっていうのが要求されるときに禁止することができるというのが強みですね
という話でした
以上一般的なファーストパーティークッキーレシピのところは以上にして続きの記事ですけども
続きというかもう一つ記事読もうと思ってたのがタイトルにあるとおりJavaScriptのメディアタイプとRc9239というところです
じゃあこっちも入っていきたいと思いますね
まずイントロからです
長いこと作業が行われていたJavaScriptのマイムタイプってやつですね
についての作業が完了しRfc9239として一応公開はされましたよと
これによって推奨されるマイムタイプっていうのがテキストスラッシュJavaScriptに統一されることになりましたと
ああいいですね
かつて推奨されていたアプリケーションスラッシュJavaScriptではなくなった経緯などを踏まえて一応解説してくださいますと言ってますね
統一されたのが結構いい話ですね
ではJSマイムタイプってところですけど
HTTPでレスポンスする際に指定するコンテンツタイプっていうのはその内容が何であるかをクライアントにインディケイトして適切な処理を促すために使用されますよと
例えばHTMLがテキストスラッシュHTMLであったりするようにJSも内容テキストなのでテキストスラッシュJavaScriptが自然に思えますねと
09:04
これは僕も一緒ですね
あんまりアプリケーションのJavaScriptって何なんだろうっていうのは詳しく調べたこと実はなかったんですけど
まあしかしですけど例えばMSが実装していたJS互換のJScript
懐かしいですねJScriptっていう名前
そのJScriptっていうのはテキストスラッシュJScriptとなりJSがまだネットスケープでライブスクリプトと呼ばれていた時代はテキストスラッシュライブスクリプトになると
なるほどですね結構歴史的にもちゃんとテキストスラッシュホゲホゲって名前だったんですね実は
じゃあなんでアプリケーションにしたんだろう
まあいいや
でまたかつてはネットスケープっていうのはJSの実装にも他の言語のようにバージョンを振っていた時代があって
まあこれはエキマスクリプトのバージョンとは異なるものですと
そこではテキストスラッシュJavaScript1.0などとなるらしいですね
えー知らんかった
でそんなこんなで歴史的に様々な指定があったが現在それらはエキマスクリプトとして語幹を吸収
まあ全てはないが語幹を吸収して単一のJSエンジンで実行されることとなった
まあ要するに歴史的にJSのコンテンツタイプっていうふうにはまあいろんな種があったんですよということです
一応なんかザーッと並べてますけど
あのテキストスラッシュエキマスクリプトとかテキストスラッシュJavaScriptとか
もしくはテキストスラッシュJavaScriptのバージョン1.ホゲホゲみたいなのがザーッとあったりとか
さっき述べたテキストスラッシュJScriptライブスクリプトとか
あとはテキストスラッシュのX-エキマスクリプトとか
あとX-JavaScriptとかまあこんなんがいろいろ種があったってことですね
いや全然知らんかった
はい
ただしJSっていうのはまあ単なるテキストファイルではなく実行されるプログラムであることから
テキストスラッシュJavaScriptではなくアプリケーションスラッシュJavaScriptが適切とも言える
SWFがアプリケーションスラッシュショックウェーブ-フラッシュかだったようにみたいなことですね
なるほどでした
実行されるプログラムであるから単なるテキストじゃないっていうところを明示的にしたいので
アプリケーションスラッシュJavaScriptっていうふうに指定されてたんですね
なるほどでした
僕の答えが出てきましたね
ここにも同じようにやっぱり種があってアプリケーションスラッシュにエクマスクリプトとかJavaScriptとか
X-EkmaScriptとかX-JavaScriptとかまあいろんなものがありましたというところですね
はい
で、WattWGですね
WattWGっていうサイト買って
こちらではそのマイムのスニッフィングの仕様にこのリストがちゃんとありますよというところで
もし興味ある方はこのWattWGのJavaScriptマイムタイプっていうところのリンクがあるので
そこを見てくださいってことでした
はい
続いてRFC4329
スクリプティングメディアタイプスっていうところに入っていきたいと思いますね
12:00
はい
いろんな今までのマイムタイプの種が乱立していたっていうこの経緯を踏まえまして
2006年にエクマスクリプトとかJavaScriptのマイムタイプに対するインフォメーショナルなRFCっていうのが公開されましたよと
このRFCでは様々なマイムタイプが適当に使われているが
その中できちんと推奨を決めてアイアナに登録しようという趣旨のものですね
はい
それがセクションタイトルにあったRFC4329
スクリプティングメディアタイプスっていうものですね
はい
ここもちゃんと詳しい内容っていうのはリンクが入ってあるのでそこを見ていただいてくださいってことでしたね
データトラッカーというサイトがあるんでそこから見てくださいってことでしたね
はい
で一応この中で一言なんかコメントがありまして
Use of the text top-level types for the kind of content is known to be problematicって言ってますので
この種のコンテンツにテキストをトップレベルタイプを使用することっていうのは問題があることがすでに知られていますよって言ってました
へーそうなんですね
以下の2つがオブソリートって書いてますね
なるほど
テキストスラッシュJavaScriptとテキストスラッシュエクマスクリプトっていうのがオブソリートってなったらしいですね
代わりに以下の利用が推奨シュッとされていてそれがアプリケーションスラッシュのJavaScriptとかエクマスクリプトっていうことだったそうですね
はいそれが2006年に立たれたRFCの中では記載されていたと
はい
これはメディアタイプはこう使うっていう部分のルールを定めたRFC-4288
後に更新されてRFC-6838になるっていうものらしいですけど
その4288にあるルールに則ったものがこれだったらしいですね
なるほど
4329じゃなくて4288がそういうものだったらしいです
詳しくはそのRFC-4288のメディアタイプスペシフィケーションズ案のレジストレーションプロセジュアルズってやつですね
っていう記事があるのでそこを見てくださいということですね
はいまあ要はアプリケーションスラッシュの方が推奨されてたっていう時代があったということですね
はい続いてのセクションがHTMLスタンダードというところです
はいまあいろんな経緯があったんですけども
だからといってブラウザーがこの2つしかサポートしないというわけにもいかないよねって話になって
もしそういうふうにしてしまうと過去に動いていたスクリプトが突然動かなくなってしまうため
結局実装を絞ることはできないと
介護感性はそうですよね
いくらRFCで定めたところでいきなり使えなくなったっていうのは世界中で大問題が起きたりしますし
そういう歴史的なサイトはもうなんか刷新してくださいっていう感覚もなくはないんですけども
はいまあ一応ちゃんとサポートしていきたいという考えがあって
で要は実装を絞ることはできない
でまぁ一方でIEQ以前っていうのはアプリケーションスラッシュJavaScriptっていうのはサポートをそもそもしていなかったため
はいデプロイ側でもテキストスラッシュJavaScriptっていうのの利用が一般的となっていた
15:01
へーこれはなんかなんだかんだ蓋開いたというか
回り回っていい設定だったんですねIEQの以前っていうものは
でまぁそうした現実を反映する意味でもHTMLの仕様は以下のように書かれていましたよというふうになります
ちょっと翻訳しますね
同様にこの仕様でJavaScriptを参照するために使用されるマイタイプっていうのはテキストスラッシュJavaScriptである
これは最もよく使われるタイプだからですと
でRC-4329によればこのタイプは公式には廃止されたものらしいです
なるほど4288ではアプリケーションスラッシュの方を推奨していて4329では実はこのタイプっていうのは廃止されてたんですね
なんだけど現代的にはテキストスラッシュJavaScriptっていうのが一応JavaScriptを参照するときに使用されるマイタイプだよっていうふうに研究は一応されてたんですね
はいこれは一応プロリクエストのWhat was it?というサイトのプロリクエストの7938で一応書かれていたってものですね
で同じプロリクエストの中に別のコメントもあって
サーバーっていうのはJavaScriptリソースにテキストスラッシュJavaScriptを使用する必要がありますと
そうなんや
サーバーっていうのはJavaScriptリソースに他のJavaScriptマイムタイプっていうのを使用しないでくださいと
また非JavaScriptのマイムタイプを使用してはいけませんってことですね
ちょっともうだいぶサーバーサイド書いてないから忘れたけどそうだったっけ
サーバーサイドの方はテキストスラッシュJavaScriptじゃないとダメなんですね
でちょっとコメントに戻りますと
つまりIETFとWhat was it?で言ってることが違うという状況だということですね
IETFっていうのはインターネット全般でのプロトコルを対象として
What was it?はブラウザ特有の話なので両者に細かな違いが起こるのは見ているところが違うっていう点では仕方がないと
まあそうですね
ただJSのユースケースを考えると何とかしたいところではありますねっていうのもそれもそうだなっていう感じはしますね
難しいですねこれなるほど
でRFC-9239Updates to ECMAScript Media Typesっていうのが出てくるんですね
はいこうした状況に対して数年前からRFC-4329の更新作業が始まっていて先日RFC-9239っていうのが公開されましたと
すごいですね4329から飛んで9239っていうのが本当に数年この辺はずっと議論されてきたってことですね
はいでそれがUpdates to ECMAScript Media Typesってことですね
はいでこの中ではJSのマイムタイプのみにフォーカスをして現状が整理されている
まとめるとこうですよと
はいRFC-4329っていうのはテキストスラッシュJavaScriptをアプリケーションJavaScriptを使うように促した
でも結局はそうはならなかった
でそことの互換を守るためにテキストスラッシュJavaScriptっていうのをコモンユースエイジとして認めますよと
18:02
他全部はテキストスラッシュJavaScriptのエイリアスとしてオブソリートするっていうことですね
あーなるほどです
方針としてはやっぱりテキストスラッシュJavaScriptっていう風にしたらしいですね
はいっていうことでした
でこれに伴ってHTML側の仕様も以下のように更新されてますよっていう風な話があってちょっとそこも翻訳します
サーバーっていうのはUpdates to ECMAScript Media Types
要はRFC-9239に従ってJavaScriptリソースにテキストスラッシュJavaScriptを使用する必要がありますと
はいここは前回と一緒ですね
サーバーはJavaScriptリソースに他のJavaScriptマイムタイプを使うべきでなくまた非JavaScriptマイムタイプを使うべきではないです
詳しくはその辺9239を見てねっていうことですね
はいっていうのがちゃんと厳密にちゃんと書かれているってことでした
はい結論としてJSのマイムタイプっていうのはテキストJavaScriptになったよっていうことでした
でまたよく勘違いされがちなんですけども
what.gではブラウザーっていうのはJSを必ず実装しないといけないともブラウザーはJS以外を実装していけないとも言ってはいませんよと
そしてもし別の言語を実装する場合はこの失敗を繰り返さないようにアプリケーションスラッシュアスタリスクみたいなものをきちんと付与するべきであるという点もRCで言及されています
あーいいですね
なるほど
で続いてエンコードキャラセットですね
はいRCの6838では同時にテキストスラッシュアスターではキャラセットパラメーターの併用も推奨していてそれに従うとテキストスラッシュJavaScriptキャラセットイコールUTF8のようになりますよと
はいしかしRC9239ではキャラセットもオプションになりましたよって言ってますね
はいここをちゃんと解説すると長くなりますが一言でまとめてしまって要するにUTF8を使えということですね
はい
別にキャラセットイコールUTF8をつけてても別にいいんじゃないかなと思ったりはしますね
はいでもオプションになったから厳密にはつけなくても良くなっているということですね
はいで続いてESモジュールですけど
はいESモジュールの登場によってJSっていうのはESモジュールの有無によって2つに分かれてしまいましたよと
どちらで解釈するべきかはJSをパースする前に知っておく必要があります
まあそうね
でESモジュール図を標準化する際にテキストスラッシュES配布モジュール図といったマイムタイプによる情報の付与を行うかどうかっていう議論になります
あーちゃんとこれ専用のマイムタイプってのも付与するんですね
なるほど厳密には確かにESモジュール図なんでJavaScriptじゃないですからね
しかしTC39ではそれはメディアタイプのスコープではないということになりましたと
個人的にはこれをやり始めると実質JSにバージョンがあるのと同じような状況になって
新しい文法は語幹を壊してもマイムを変えればいいという前例を作ることになるために避けられたんだろうなというふうに思っていますと
21:04
なるほどですね
TC39はメディアタイプのスコープではないというふうに議論がされているんですね
これはめんどくさいな
とりあえずテキストスラッシュJavaScriptっていうのはESモジュール図であろうとも変わらないことが一応明示はされましたよということですね
なるほどねメディアタイプのスコープではないっていうふうに指定し始めるといろんなところでめんどくさいことになるんだろうなってことですね
この情報を提供するためにNodeとかDenoっていうのは.mjsをはじめとした拡張子であったりパッケージJSONなどをサポートして
ブラウザーの場合はScriptType="modules".っていうようなHTMLタグによってそれを知らせることになりましたよというようなですね
そういう歴史的背景があってScriptのタグの促成にType="modules".っていうのをつける感じになったんですね
面白かった
最後ですねアウトローというところですけどJSONのMIMEタイプっていうのはESモジュール図であろうとなかろうとテキストスラッシュJavaScriptになる
UTF-8でエンコードすべきとなりましたよっていうのがとりあえずの結論ですということでした
一応デモもあるらしいですねネモサイトがあって本サイトがH2をデフォルトでアプリケーションJavaScriptであったものをテキストJavaScriptに修正して
H2Oに一周プリンク済みでありますよと言ってますねこのデモサイトというのがH2Oというサイトらしいですね
ファグと他のリソーシーズというところで参照記事のところがだーっとリンク貼ってます基本的にはRFCのリンクだらけですねこれは
であと最後いくつかの一周とかブレイクスのところもリンク書いてましたよということでした
はいちょっと面白かったですねJavaScriptのメディアタイプって要はテキストJavaScriptに統一されるということには変わりはないんですけど
はい で一応それがRFC9239ですねあの最近出たものだと思いますけどこれに書かれているんでまあ詳しいものをこれを見てくださいということでした
はいいやーなんか面白かったな全然この辺勉強したことなかったしRFCをそんなちゃんとガッツリ読んだことは実は僕なかったので
この辺は良かったなと思います
じゃあ最後ですねえっと30分なので残り時間どうしようかなと思ったんですけどもう1個全部読み切らなくて良さそうであれば
まあちょっともう1個読んでみたかったっていう記事があったのでそこに入ろうかなと思いますはいちょっとまたJavaScriptの話になっちゃうんですけど
processing arrays non-destructivelyっていう記事ですね
例えばforb vs reduce vs flatmapみたいな
っていうところですね要はそのJSの配列の周りに関する各メソッドに対していつ何を使うかみたいなところを
言及した記事ですねまあそこをちょっと読んでいこうかなと思います途中ソースコードだらけなんで
24:05
コード自体はなるべく説明しますけど基本はハッシュロード思います
なのでちょっとわからないかもしれないしまあ頭の中で想像していただく形になるかもしれないですけど
まあお付き合いいただければなと思いますはいじゃあ入っていきましょうと
このブログではarrayを処理する3つの方法について説明してますと
その一つがforb loopともう一つがarrayメソッドのreduceですねでもう一個が配列メソッドのflatmapですね
この3つですでも目的っていうのはそのarrayを処理する必要があるときにこれらの機能から選択できるようにすることですよね
あとreduceメソッドとかflatmapメソッドをまだ知らない人ためには一応両者を説明しておきますと
説明しますねってことでしたねこれら3つの機能が説明しますって言うけど説明は特にないのか
これらの3つの機能がどのように機能するかをよりよく感じてもらうためにそれぞれの機能を使っていいかのものを実装してますよと
まず入力の配列にフィルターをかけて出力の配列を作成しますと
各入力の配列ですね入力配列の要素を一つの出力要素の
出力配列の要素に対応させますと
各入力配列の要素を0個以上の出力配列の要素に展開します
あとフィルターマッピングですねフィルターとマッピングを一度に行うことと
あと配列の要素を計算しますと
あと配列要素の検索もしますと
あと全ての配列要素について条件をチェックしますというようなものについて実装していきますと言ってますね
全ての処理は基本的には非破壊的に行われますよと
入力の配列は決して変更されていません
また出力が配列の場合は常に新しく作成するようにしていますよというのが前提になりますね
はいでテーブルオブコンテンツもすごい長いんでガンガン行こうかなと思いますね
はい
まずはフォーブループのところからですね
プロセッシングアレイズビアーザフォーブループって書いてますからね
はいまずはですねフォーブによって非破壊的に配列を変換することができるようになりますよと
例えば変数リザルトっていうのを宣言して空の配列で初期化をとりあえずしておきますと
で入力配列の各要素エレムってのがありますね
はいあの
えっと4の中でやってます
4をコンストエレムオブアレイっていうのがあって
はいまあそういう関数を今回作っておいて引数にアレイってのが落とされてます
でそのアレイに対して4オブでループを回しますよってことですね
はい
でこの各入力配列の値エレムっていうのを受けるのでそのエレムに対してリザルトに値をどんどん追加していきますと
今なんか条件があってその条件を満たしたらそのリザルト.プッシュっていうのでエレムにどんどん追加をしていって
最後にそのリターンでリザルトを返しているという感じですね
はいでもしリザルトに値を追加するのであればエレムも必要に応じて変換してリザルトに代入すればいいよっていうのが
27:03
とりあえず4オブの使い方ってことでしたね
はいまあこれは基本的に使い方知ってる方は全然あの
ふーんとかいつも通りの話だねっていうことになると思います
はいはいはい
で一応テストも書いててassert.deepequalでまあ一応ガーッとテストも書いてるんですね
はいはいそういう感じです
で続いてwe can also use 4オブ to implement the array method.mapって言ってますね
はいまあ.mapメソッドを伴った4オブループってのも一応ありますよねって話をしてますね
はいで言ってるけどえーっと今ソースコード見てるんですけど別にマップ使ってない気がしますねこれ
はははは
だからマップいやでもマップメソッドってちゃんとえーっとタイトルには入ってるんですよね
けどマップメソッド特に使ってないのでこれは多分コードの記述間違ってる気がしますねこのブログ
さっきのコードとほぼ一緒なんですよね
ふーんまあ一応マップも使いながらできますよっていう話だと思いますとりあえずは
はいであと次はexpanding with 4オブですねはぁはぁはぁ展開をするんですね
で今回定義しているその特別なコレクトフルーツっていう関数ですねまあフルーツを集めますよって関数で
これっていうのは配列内の要素が持っている全ての値段をとりあえず返しますって言ってますね
とりあえず4オブの使い方としていろんなものをやってますってことですねはい了解でした
最初の基本的に書く4オブとかフラットマップとかっていうそのメソッドの説明のことが
だーっと書いてるんですねひたすらはいはいはいまあそれをいろんな使い方でやってるところですね
さっきはマップを使ったんですけど今度はフィルターマッピングみたいなものを組み合わせてやってみたいとか
はいあとコンピューティングサマリーっていうのでサマリーを計算してそれを返すみたいなことだったりとか
そういうところがバーっと出てくる感じですねなので一旦そこはどんどん端折っていきたいかな
そうするとこれ多分セクション3から入るのが良さそうな気がしますね
はいっていうかもう結論を聞こうかなあのレコメンデーションとフューチャーリーリング
フューチャーリーリングはどうでもいいレコメンデーションだけ読みましょうかね時間ももう9時半近づいているので
はい まあどれがいいのかっていうところのレコメンド推薦ですね
推奨かっていうの入っていきます
これらのツールを使ってどのように配列を処理するのがベストなのかっていうのを細かなものをはじめますけど
大まかな水上事項との以下の通りになりますよと
とりあえずタスクに最も適したものを使いましょうと
フィルタリングが必要ですかとフィルタリングが必要ならドットフィルターを使いましょうと
マップがそれ必要だったらもどちらもドットマップを使ってくださいと
要素の条件をチェックする必要があるんだったらサムとかエブリィを使いましょうなどなど
はいまあいろんなものありますけどそれぞれ必要なものを適したものを使ってくださいってことでした
でフォーオブっていうのは最も汎用性の高いツールですと
30:01
で私の経験では関数型プログラミングに慣れている人っていうのはリリースとかフラットマップを好む傾向にはありますと
はいでそうでない人っていうのはフォーオブの方がまあ理解しやすいって思うことが多いですね
しかしフォーオブっていうのは通常結構冗長なコードになりがちですよねっていうふうに言ってますね
はいでドットリリースっていうのはアキュメレーターを変更する必要がなければ
まあ括弧全ての要素の合計をするみたいな
まあそういう要約を計算するには結構適してますよということですね
はいアキュメレーター変更するって必要があるんだったらちょっとリリースは逆に使わない方が良さそうです
で最後ですねフラットマップっていうのは入力要素を0個以上の出力要素にフィルタリングして展開するには優れてるんで
そういう時に使ってくださいってことでしたね
はい
ということでしたまあなんか参考にはなったけど個人的にはふーんって終わってしまったな
というところですまあ一応さっき言ったこのなんだっけ
フラットマップとリリースとフォーオブループの一応なんか使い方がね結構細かくいろんなパターンで
あれですねサンプルコードが載っているのでこの記事自体単純に勉強にはなりますね
はいであとコードだらけなのでこれは多分皆さんの方で見ていただく方が多分良いのかなと思ったりはしました
はいちょっとすいません最後の方ダラダラっとグダグダしてしまったんですけど
一旦じゃあ今日の朝勝はこちらで以上にしようかなと思います
はい次回はまた何を読むかっていうのは何か見つけろって読んでいきたいかなと思います
でまたですねちょっとこの後ツイートするんですけど朝勝の読む記事のアンケートをちょっと取ろうかなと思います
自分でもぶっちゃけるとどの記事を読むかって毎回悩んでいるのでその辺を聞いてみたいかなと思います
まああのざっくりと言うと例えばJ3インフォみたいなもののニュースの一覧ですね
ウィークリニュースとかで結構あのサイトがまとめられてるんでそれを上からガーッと舐めていく方にするか
やっぱりそっからピックアップした今みたいにこの記事この記事のピンポイントで読んでいくかどっちにしようか
あとはさっき言ったですねTC39とかRFCみたいなところですね
そういう結構原理とか議論するものっていう使用周りのところを読んでいくのがいいのかとか
あとは最新ツールのドキュメントだったり機能みたいなところをどんどん紹介していこうか
そんな感じのアンケートを一応取ろうかなと思っているので
もしよろしければ回答いただけるとすごく嬉しいなと思います
はいじゃあちょっとダラダラと言ってきましたけど
一旦今日の朝活はこちらで以上にしたいかなと思います
はいご参加いただいた皆さん本当にありがとうございました
じゃあ今日からまた月曜日ですね1週間頑張っていけたらなと思います
はいじゃあお疲れ様です
