マイクの変更とその影響
こんばんは、Replay.fm第43回です。
こんばんは。
うっす。
うっす。
いやー、特に言うことないな。
マイクが変わりました。
あー、おめでとうございます。
ありがとうございます。
それさ、一番最後に言って、分かりましたかって。
あ、ブラインドテストするべきだった?
うん。
確かに。
逆を試すスタイルでも良かったかもしれない。
いやー、分からんって。分からんよ。どうせ分からん。
編集前の生音をお届けしないと分かんないかもね、それこそ。
あー、それもあると思うし、やっぱその、なんていうか、部屋で撮ってるとさ、なんか、
いろんな要因が絡んでくるから、あんまり、別の日に撮った音源で、別のこと喋ってて、比較ができるとは思えない。
横に並べて同時に撮ったらさ、きっと、分かる人は分かるだろうし、分からない人は分からんだろうし。
確かに。
まあ、なんか、明確に差が出てくるんだろうけど。
まあ、じゃあ、それで言うと、最初にマイク良くなりましたって言って、
あ、良くなったかもって気持ちで聞いてもらう方がいいね。
あー、その方が幸せだよね、みんなに。
うん。そう言いましょう。プラシーボ。
誰も聞いてないのを精神で言ってるけど、まあ、ちょっとマイクが変わりましたという。
いやー。
まあ、逆に聞き苦しかったらね、それは教えて欲しいかも。
あー、確かに。
一応なんかね、合わせたんですよ。フリーアンプの設定も、なんか、さっき合わせたのとか合わせ込んでて。
はいはいはい。チューニング済みですと。
そうそうそう。
偉いなー。
ちょっとゲイン取りにくくなったので、なんか、ゲイン上げたりとか、アドブットの音量上げたりとかしてるから、なんか、いろいろ変わってると思いますが。
お楽しみくださいね、そんなイヤゲシの声を。
いや、でもお楽しみいただきたいのに、今日は史上最小数の記事っていうね。
CLIツールについての考察
なんか、熱くて読む気なくなってきてない。
ね。
いや、なんかさ、この、本当はさ、この難数CSPバイパスの記事とか、
あー。
なんか、この辺は読んでもいいかなってちょっと思ったんだけど。
うん。
なんか、いいかなって。
そうか。
僕はちょっと読む、これ唯一今週読めなかったな。
うーん、ちょっと俺もね、なんか、ちょっとしんどいなって感じがした。
うーん。
ちょっと忙しかったね。
忙しかったね。
うーん。
まあでも、サボってるわけじゃないからマジで、みんなの集まってしてるだけだと思う。
なんかさ、読むフィードの、登録してるフィードの数、徐々に増えてるから、それでもこれなんだな。
そうなんだよね。
なんか最近私、禅のトレンドをあのフィードに入れたわ。
へー。
なんかめっちゃ禅のフィードが入ってくるようになったんだけど。
はいはいはい。
セキュリティとか全然関係なく入ってくるようになった。
禅さ、すごい生成アイの記事多いよね今。
あー、そうかな。
トレンドそうでもないのか。
ビットリフ閲覧ツールの話とか。
うん。
トレンドで言うと、まあ、結構散ってる感じはするけどね。
うーん。
なんかあの禅から来るその急上昇ランキングみたいなメール。
この前見たら、クロードコードとジェミンだっけな。
なんか爆増してて。
うんうん。
もうなんか生成アイ一色みたいな感じで。
えーと。
なるほどね。
ちょっともう見てみよう。
まあ上から行きますか。
行きましょう。
はい。
1個目は、えーっと、あずさんのブログで、
エアーエージェントのコマンド実行にタッチIDを使った
人間の確認を挟むCLIツールConfirmPamを作った。
まあ、作ってみました記事ですね。
はい。
まあ何かって言うと、多分まあタイトル通りではあるんだけど、
まあ読むとちゃんと、
僕はなんかタイトルだけ見た時に、
どこでどう使うんだろうと思ったんだけど、
まあ読むと結構なるほどって感じで、
その、まあ作ったものはタイトル通りで、
えーっと、何でしょうね。
その、結構シンプルなのかな。
そのコマンド実行、引数に、えーっと、
このコマン、実行したいコマンド渡して、
ConfirmPamっていうのを叩くと、
えーっと、多分タッチIDでこれを実行しようとしてます。
yes、noみたいな感じで、
あのー、タッチID認証挟むことができて、
で、通すと、えーっと、まあステータス0を返すし、
えーっと、拒否すると、まあ失敗。
STDアウトを返すっていう、
STDエラーを返すっていうような、
実装になっていったものですと。
で、まあどこで使うことを想定しているかで言うと、
まあ知らなかったんですけど、
例えば、えー、皆さん大好き、
クロードコードやGemini CLIはちょっと、
まあでもクラインとか、
その辺がその裏側でGitコミットを叩くと思うんだけど、
その時にNo Verified Optionみたいなのを
勝手に付けがちみたいな話があって、
そうね、うん。
まあ割とカジュアルにこれやってくるよっていう時に、
このGitの、Gitコマンドね、あれかな、
エリア数として書き換えちゃって、
この中でConfirm Pamを、
まあNo Verifiedが入らない、
No Verified Optionが付いた場合にこのConfirm Pamを挟んで、
まあ人間の確認を挟むっていう風に仕込んでおいて、
安全に使うみたいな例とか、
あとはそのCLとかすかね、なんか、
まあ記事中で振られてるのは、
本番にデプロイするようなシールがあったら、
その中でConfirm Pamを挟んで、
人間の確認を挟むっていう風に使うっていうのが
ユースケースとして上がってるって感じ。
でまあ今までだったら人間がこれを実行するか、
多分実行する時点で人間の確認がされてるっていう保証になってたのが、
まあAIエンジェントが叩くことに
人間が確認してないパターン、
特にオートパイロットでしたっけ、
オータープルーヴ状態だと、
まあどうしても知らず知らずのうちにっていうのは、
まあそこに対してユースケースを実装したんだろうなっていうと、
結構なるほどって思ったというか、
いい?いい?着眼点といい?
いいサイズ感なんだよね、なんかすごい。
ものはすごいシンプルなんだけど、
ユースケースはめちゃくちゃ思い浮かぶし、
応用も効くなっていうところ。
そうね。
まあ一方、クラムシェルミンのYはちょっと…
でもさ、クラムシェル…
別にパスワード入れればいいだけなんだけどさ。
まあそれがめんどくさいって話もあるっちゃうかな。
タッチIDまで行かなくてもいいのかもね。
コンファーメーションができればいいという説はある。
まあぶっちゃけプロンプト出して、
はい、家でも済むっちゃ済むよなと思って。
ファムじゃないといけないんだっけ感は、
まあ若干問案でもないけど、
まあでもいいんじゃない。
プロンプト出すほうが実は大変とかあるのかな。
マックOS事情わかんないけど。
いやー…
いやー…
プロンプト…
なんかAppleスクリプトとかでポンと出せた気がしたことわかんねえな。
なんかいろいろ結構細かいハックがあって、
まあないことはないような気もせんではないけど、
ちょっとわからんな、パッと出てこない。
まあありそうである。
まあいろいろ考えてこれにしたのかな。
まあでもパスワードへのフォールバックとかがしやすいので、
PAM使ってるし。
あとあれだな、思ったけどダイアログだとポチてん倒したら通っちゃうから、
ちょっとミス…
まあエージェントのあれによっては普通に、
まあ確かにね、ポンと出た瞬間にたまたまリターンを押すタイミングがあると通っちゃったりするし。
反射でポチポチとしてやべみたいなのはありそうになりました。
まあだから用途に対してはこれが正しいんだろうね。
あとは作ったばっかだから使ってみて、
まずさんは粘り強くめっちゃ改善するイメージをやってくるんだろうね。
なんかね、PAMTID.SOっていうPAMモジュールがあって、
クラウドフレアの記事の紹介
で、なんで、
SUDUのパスワードの認証もTouchIDに置き換えられたりするんで。
ああ、そうなんだ。
うーん。
知らず。
その辺ちゃんと読んでるのかな。
でもAppでが入るとね、なんか普通に書き換えられたりとかして。
まあ、Appleっぽいな。
そうそうそうそう。
なんでまあちょっとどうしようもなかったりするんだけど。
あと普通にEDRとか入ってるとなんか怪しい動きとして検出される。
確かに、そういうのありそう。
会社PCでやってて一回連絡来てた。
なるほどね。
そう。
いやー重いな。
いやーこういうのいじりてえな。
悪いよな、MacOS。
一回機種変更したときのインストールスクリプトを多少自動化してるんだけど、
そのときに結構キーリピートの感覚とか音量の設定とかもいろいろいけるじゃん。
ああ、そうだね。デフォルトセットじゃ全部できるね。
そうそうそうそう。
できるね。
その辺見たときにへーって思いながら。
でも割とハッキーだしちょっと。
2年後には死にそうだなって思いつつもちょっと重いなって思ったりして。
しかもなんか微妙にいじれたりいじれなかったりするから。
そうそうそうそう。
その、あんまなんか結論はあっちでやんの嫌だなっていうあれになったわ、俺は。
ああ、ほんと。
一回やろうとしたことあって。
うん。なんかね、その有志というかそこに熱い思いを持ってる人が書いてるレシピみたいなのとかラッパーみたいなのがあるから、
そういうのを使ったっていう感じです。
もうちょっと覚えてないけど。
いやー、はい、まあちょっといいですね。
機会があったら使いたいなって思ってます。
じゃあ次行きますか。
ああ、はい。
Introducing Paper Crawl Enabling Content Owners to Charge AI Crawlers for Access
っていうクラウドフレアさんのさん、クラウドフレアさんの記事ですね。
これなんかTwitterはね、スイッチ2ネタバレポーションのために僕は最近実は全く見てないんですけど、
なんかちょこちょこ。
早く早く変えよ。
早く変えよ。
殴るぞマジで。
早く変えよ。
キックするぞこの収録部屋からマジで。
まあいいんですけど、その、なんか、まあでもその、アンドロイド、僕のアンドロイドフォンのレコメントしてくるニュースには
これ日本語版みたいなのがめっちゃ出てるから、あれになるところではなってるのかなとか思いつつ。
ああ、402がついに普通に使われる日が来るってこと。
確かにね。
まあこれどういう記事かっていうと、タイトル通り、言っちゃタイトル通りなんですけど、
クラウドフレアの新機能
これね、このタイミングで実はクラウドフレア5個ぐらい記事出してて、全部これ絡みの記事なので、その辺の話もちょっと混ぜていっちゃうと、
その、何でしょうね、この生成AI時代になって、AIのクローラーのアクセスが急増してますよって話がそもそもあって、
でこれぐるっと具体的にどのぐらい増えてるかみたいなのを別記事で書いてて、おもろいなと思ったんだけど、
アクセス数っていうよりかはその記事はアクセス数に対して、ボットのアクセスに対して実際に利益のあるアクセスが何件稼げたかっていう指標を分析した記事があったんだけど、
従来だとGoogleのSEOボットがあるじゃないですか、あれとかは14アクセスあたり1ペーパービュー稼げるっていうケースになるらしい。
なんでコンテンツ提供者と検索エンジン側でインデックスするっていう部分の割と利害が一致してたよねっていう部分があったんだけど、
それに対してオープンAIは1500アクセスに対してやっと1アクセス稼げる、実際の人間だし、
アンソロピック2探偵は7万3万クロールに対してやっと1アクセス稼げるっていう状態なんだけど、
皆さんご存知の通り、あえてチャットでこれ調べてって言って裏側でアクセスしてそのコンテンツをチャットが出してくるっていう状態だから、
本件アクセスされるってことはほとんどないし、何か収益が入るとしたらAIサービス側に入るっていうところで、
ウェブホスティング側としてはちょっと時代が変わったよねっていうのがあって、
そういうところに対して、AIのクローラーに対してだけクラウドフェデア型設定することで課金をさせるっていうのができるっていう仕組みを実装しましたって話ですね。
この記事は料金の話だけど、他の記事だと例えば広告を表示するページだけクロールをブロックするとかもできたりとか、
あとマネージドでrobots.txtを提供するような仕組みも同時に多分リリースしていて、
それはもうクローラーが遵守するかどうかっていうのは査定置きなんだけど、
このクローラーを許可してこのクローラーはダメとか、AIのクロール全般ダメっていう設定をコンソールでポチポチやると、
それを反映したrobots.txtが同時に入るみたいな設定もリリースされていて、
全般的に割とコンテンツクリエイター側に寄せたリリースをしているっていう仕組みですね。
なるほどね。
なんかこれ通して見たら広告とか気にせず記事の中身が取ってこられるとかだったら最高だけどな。
なんかそうなったら結構ウィンウィンだよね。コミュニティの意味だなって思う。
そうなったら結構いいなと思いつつ、一方でこういうのを通じて
生成AIとかがエコシステムとして依存しているあらゆるものが有料化していく可能性もあるわけじゃないですか。
そうすると価格に転換されるだろうなとは思うから、低価格化が進まないだろうなと。
確かにね。
結果的に取れないコンテンツとかが結構いっぱい出てきちゃうとやっぱりAIの価値みたいな部分が既存されるだろうから。
あと前話してたけど、広告をホスティングする場所がそのコンテンツ側から映画に移動してくるっていうのはあるかもね。
あるかもね。
裏側ではコンテンツ等にお金がかかっていて、それをどう転換するかで課金させるか、フリーミアンで広告見せるかみたいな。
さりげなくハルシネーションっぽく広告を混ぜていく。
最悪。
あ、でもなんかちょっと面白いな、レスポンスに混ぜるってことでしょ。
ちょっとおもろいな、それ。
ところでこの冷蔵庫欲しくありませんか?
脈絡ねえな。
なんかそのものによってはさ、おすすめのレストラン教えてとかでさ、
Googleマップとか今あるじゃん。レストランで検索すると多分広告課金してると、広告用の特定アイコンでちょっと目立ちやすくするみたいな。
あれみたいなノリでそのレスポンスに混ぜてくる。
お金払ったら混ぜてくるとかあるのかな。
いやでもそれこそなんか、でもそれを多分さ捨て巻き製法とかさ、多分いろんなものに引っかかると思っていて。
その、見せ方によるだろうけど。
見せ方のそのガイドラインはセットは来ます。もちろんするけど。
これはアドですみたいな行で。
いやー懐かしいな。新卒の時にその辺の会社だったからすげえ、アドの世界大変だなって思った記憶があった。
まあまあまあ。
いやーこれね、まだなんか動き出したばっかだから、よくしていこうという感じでフィードバックを集めますみたいなことを書いておりつつ。
これなークラウドフレア使ってみたいなー。
なんか自分のサイト、別に誰もクロールしてない気がするけど、ちょっと導入してみたいなと思った。
使ってみた。
いやーなんかさー。
うん。
うーん。
クラウドフレアって結構いろんなもの持ってるよね。
結構いろんなもの持ってるね。
なんかその割にあんまこうGoogleみたいななんか叩かれ方をしてないわ。なぜなんだろうね。
あー、確かにね。
うーん。
相当いろんなもの持ってるはずだし、なんか相当いろんなもののそのコントロールをこうクラウドフレアに任せてる。
世の中一般の人たちがいろんなもののコントロールをクラウドフレアに任せてしまってる部分ってあると思うんだけど。
まあでもGoogleの場合叩かれてるっていうのはなんか僕が今想像したのはそのAndroidをChrome売却話とかだと思うんだけど、その辺のなんだろう。
まあちっぽけじゃないけど。
今のポートフォリオ的には何かを独占するとか、またプライバシー周りとかだよね、よくそのGoogleに限らず叩かれてる系でいうと。
っていう部分でいうと、クラウドフレア自身は何かを集めてるわけじゃないっていう部分で叩かれづらいとかあるんじゃないかな。
なるほどね。
ぱっぱと思うところだと。
あくまでCDNだし、そのまあエッジにいろいろデプロイみたいな話もあるけど、あれもそのある種クラウドプロバイダーの範疇だと思うから。
中に、中のデータを産むんじゃなくて、何かホスティングする場所を提供してるって話だし。
まあこれとかはむしろ、なんていうか、言語されやすいよね、おそらく。
まあね、だからまあ結構いいとこ攻めてるんだろうな。
そんな気はするね。
面白いね。
エッジのワークワークとかね、あの辺はすごい、クラウドフレアが圧倒的に先をいってるかもしれない。
気になる方は、ぜひご自身のページを課金のページにしてください。
いやこれ思ったんだけど、ちょっと様子見よう。
みんないくらにするんだろうって思って。
値段つけらんねえと思ったんだよな。
1アクセス0.01円くらいでいいけど。
じゃあ次ですか。
AWSとTagDBの活用
データ基盤のAWSセキュリティレイクに対するCMクエリエンジンをTagDBにするとサクサクで楽しい話。
レイアXエンジニアブログの記事です。
いつものケンゴさんの記事です。
カニーさんとかも結構こういうの好きそうだなって思いながら読んでたんだけど。
今回はケンゴさんなんだなと思いつつ。
ケンゴさんめっちゃブログ書いてくれるよね。
Athenaの話で、
AWSコンソール上でのレイテンシーが結構しんどいよねみたいな話がありつつ。
なので検索エンジンみたいなクエリエンジンを別で持つとサクサククエリかけて検索かけられて楽しいよっていう記事ですね。
具体で言うとS3にたぶん構造化ログを残しておいて、
それをTagDBから参照するよみたいな話なのかなと思うんだけど。
そう、どう思う?
恥ずかしながらなんかTagDBってそういう感じのやつなんだっていうのを初めて知った。
いやーわかる。僕も恥ずかしかった。
名前はめっちゃ見るけど、それが何なのかよく知らなかったから。
なるほどね。
なんかめちゃくちゃ有用なユースケースだって普通に思った。記事を読む感想として。
手軽なのはいいね。
なんかそのさ、さっとこの時期のコネのログをさっと見たいみたいな時にさ、
この記事書いてあるところの、どれだっけ、宛名か。宛名で何分待たされてとかちょっとよくわかんなくてとか、
UI開いてみたいなところがローカルでSQLでババッてやれるのはマジでいいなって感じ。
求めてる世界観。
S3だからさ、なんか結構雑に放り込んでおけるよね。
そうだね。
何してーなー、Google Cloudですけど。まあでも原理性は別に同じ。
GCSで普通にいけると思うから。逆に何かAthenaとかそのAWSのプロダクトとかに関係なく使えるプラクティスとしてめちゃくちゃ有用だなと思うし。
いや、ちょっと作ってください。
頑張るかー。今年一回で頑張ります。
作ってください。
さて、TAC-DBなんか社内に詳しい人いた気がするんだよね。
あら。
確かに。ツイートしてたから詳しい人いた気がするんだよね。
TAC-DB、えー。
いやーけんこうさんいいよなー。こういう絵も記事もありつつこういうなんかチップス記事というか、ただただ役に立つチップス記事も出してくれて。
ね。
ありがたく思って。
僕らもいろいろ出していきたいですね。
そうね、間違いない。
いやー、記事書いてる余裕がねーんじゃー。
俺はもう強い意志で2週間に1本目標を買っていったんですよ、自分の中で。
いや、えらっ。
ネタは溜まってるからさ。
あー、俺もね、そのタイトルだけ静かなインターネットにこう突っ込んでる記事がね、結構ある。
いやでもいいじゃん、その、いやーでもなー、その鮮度大事なんだよなー。
そうなんだよ。
あんまねーやりすぎると忘れちゃうんだよね。
うーん。
いや、トラブル強いしね、時間は。
そうなんですよ。
そうなんですよ。
あとはAIに書かせよう。
AIに書かせんの?
いやー、この記事はクロードコードが書きました。
クロードコードが書いたものを遂行しましたと。
あー、クロードコードが書いたものをChatGPで構成しました。
温かみがあるねー。
めちゃくちゃいいじゃん。
ちなみにプロンプトはこちらです。
いやー、やってこう。
あー、ちょっと今1個、あれだ、下書きにしとこうと思ってたやつが出ました。
結構たまってきたなー、なんか。
なんかね、いろいろあって、その、何を話し、何を話さないか。
ロクロマースタイプの峠と転植の共通点の話とか。
おもろいな。
執筆の方針
想定リスクの最大値をどこに置くか。
想定リスクの最大値をどこに置くかの話と。
あとはソフトウェアエンジニアとセキュリティエンジニアの話を今追加した。
なるほどね。
いやー、待ってます。
次は間に合わないだろうか。
次の収録でこの場で読めるペースで行きましょう。
もっと言うとね、入社1ヶ月経ちましたの記事を書きたいんだけど。
あー、確かに。
それこそね、タイミングの問題なんだよな。
もうさ、なんか、10日が経とうとしてるからさ。
そうだね。
もはや逃した感はある。
なんか、3ヶ月とかで書けばいいかな。
3ヶ月で書くか。
入社3ヶ月経ちましたの下書きを入れるとこ。
うん。
絶対書かない。
書く気がしないけど。
まあ、こういうのは寸読と一緒だね。
気持ちが大事だね。
そうね。
はい。
まあ、皆さんお楽しみに。
待っててください。
はい。
えー、最後か。
早いね。
早っ。
約束、いっぱい寝よう。
Next.jsのサーバーアクションズ
えっと、神名さんのエンジニアルブログで
Next.jsのコンパイラーから知るサーバーアクションの完全解析、
セキュリティ上の注意点も含めてっていう記事ですね。
いつもの西川さんじゃない方が書かれた。
フロントエンドチームの方なんですかね。
うん。
そういうのよくないよ。
何々さんじゃない方みたいななんか。
確かに。
よくないね。
いや、そう、そう思いました。
来たんだキフィとオカリアさん。
いや、神名さんのブログ、いやでもこのブログすごいよかったです。
あの、渡辺さんがすごい覚えております。
スタッドハックカンパニーの渡辺さん。
まあ、固定の誰かが書いてないっていうのいいよね。
そうだね、確かに。
いつもこの人だよねみたいな感じよりはなんか、
いろんな人が登場するのいいなと思うし。
間違いない。
ありがとうございます。
どういう記事かっていうと、
Next.jsのサーバーアクションズっていう機能があってですね、
知ってます?
知らないです。
なんかね、僕も実はフワッとしか知らなかったんだけど、
それの解説も詳しくしてくれてるし、
その仕組みみたいなところをコンパイラー、
挙動の解説を含めてやってくれてるって記事で、
全部触れてるとちょっとあれなんで、
詳しくは読んでほしいんですけど、
超ざっくり言うとサーバーアクションズっていうのは何かっていうと、
SSRのフロントエンドのウェブアプリケーションを作るときに、
バックエンドのAPIがほぼ欲しいじゃないですか、
ほぼ必須というか、
裏側でデータをサクセスしてデータを取ってくるとか、
データの更新を行うとか、
外部のAPIを通信するとか、
いろんなエースケースがあると思うんですけど、
そのAPIを実装したいっていうので、
なったときに、
Next.jsのサーバーアクション、
違うわ、
Next.js自体、
最強のSSRだったら、
サーバーも立つんで、
フロントエンド開発の課題
そのサーバーにAPIのエンドポイントを生やすってこともできる。
いやー、今時だな。
リミックスとかもそういう感じのアーキテクチャだよな、多分。
そうだね。
ちょっと違うか。
ちなみに今はリアクトルーターですよ。
リアクトルーター、
死にました。
そうだよね。
死んだんだ、あれ。
そうだね、リミックスの更新はもう終わってる。
終わったんだ。
リアクトルーターV7、V5だっけな。
にマージというか。
なるほどね。
だからリアクトルーターのアプリケーションを見てるとリミックスっぽいんだね。
そうそうそうそう。
だから、昔のリアクトルーターを知っている人からすると、
今のリアクトルーターは全く別物なんですけど。
いやーマジさー、もうフロントエンド、
無理だよ、無理。
無理。
なんかもう覚える気もなくなってくる、普通に。
頑張って、頑張ってついてきて。
サーバーアクションっていうのがあるんですね。
これはAPIを実装できるって話じゃなくて、
今僕が言ったのは、従来の例えばエクスプレスみたいなものを
フロントエンドと同じ場所にかけるって話は当然として、
その一歩先として、
今言ったアプローチだとエンドポイントの実装があって、
それをフェッチとかで叩く実装を書くっていうセットで
やんなきゃいけないじゃないですか。
なので、もっと楽にやりたくねっていうところで、
サーバーアクションっていうのを使うと何が起きるかっていうと、
サーバーアクションズのファイルを1個実装して、
その中にAPIのロジックを書くじゃないですか。
それはモジュールとして書くんですよ。
エクスポートファンクションみたいな感じで書いて、
クライアント側でそれを、
APIを叩くんじゃなくて呼び出すんですよ。
なるほどね。
コードレベルでは透過的にそこが使えるようになっているけれども、
実際に動かすとフェッチが発生して、
かつてSSRだと直で呼び出してるような動きをするわけだ。
そうそう。
なのでコンパイラーが出てくる理由は、
最終的にはAPIエンドポイントが速すっていうサーバーのコードと、
それをフェッチで叩くっていうコード。
フェッチかどうか、多分フェッチだと思うんだけど、
そういうコードに吉成になっていく。
この図とかはわけですけど、
こうなってるんですよ。
ここが今までは、
フロントエンド側のコードで、
サーバーのやつをインポートしてるんだけど、
今まではフェッチで、
このセンドデータのエンドポイント決めて叩くっていうのが、
こういうふうに書けて、
嬉しいねっていうのが、
超ざっくり言うとサーバーワークション。
なんか嫌いじゃないけどな。
何て言ったらいいんだろう。
分からんけど、
フロントエンドの開発を実際にしてる人たちが、
これを見てどう思うか分かんないけど、
フロントエンドの開発をする中で、
ちょっと一個分かりにくいなって、
自分が思ってた部分が、
少し解消する気がする、これで。
なるほどね。
要はこれは、
ライブのエンドポイントを呼ぶのか呼ばないのか、
みたいな部分の悩みが一個なくなるから、
気にする必要がなくなるっていう。
ちょっといいかもなって、
これ見た限りは思う。
そうね、呼ぶようかな。
まあ、書き味としては多分書きやすいのかな。
うん。
ただ、まあなんかその、
一方で、
まあこれ自体はかなりずっと賛否両論で、
なんかすごいふわっと眺めてるんですけど、
何だろうな。
まあ、割と分かりづらいというか、
この機能をちゃんと知ってないと、
コンパイラされた先でどういう挙動をするか、
みたいな部分が、
想像できなくなっちゃうんで、
そのごちゃ混ぜにしちゃうと、
サーバー側で本来は隠蔽したり、
まあ何でしょう、
データベース処理とかAPIトークンとかが、
まあ容易にフロントエンド側に
露出しちゃうよって話があって、
まあそれがなんかそのタイトルに含まれて、
セキュリティ上の注意点も含めてっていう部分の話。
ちょっとなんか、まあ確かにそうだね。
これ渡されてセキュリティレビューしてって言われたら、
ちょっとうってなる感じがするね。
うん。
使う側としてはいいのかもしれない。
そうだね。
で、まあこのコンパイラ先で具体的にどうなるのか、
みたいな部分がめっちゃ詳しく書いてあるので、
そこはまあぜひ読んでくださいって感じだけど、
あとはその癖があるものとしては、
クロージャーを使うとちょっと挙動が、
暗黙的な注意点があるから、
それも気をつけてみたいな部分も研究してて、
要研究してるなみたいな部分がありつつ。
へー、いいね。
なんかね、暗号化とかも吉野にやってるっぽくてすごい。
いやー、要やってるなって感じなんですけども。
へー、なんか地味にいい記事シリーズだね、今年の。
うん、そう。
で、まあ、でも僕のちょっと個人的な感想としては、
これはやっぱ人類に入るんじゃないかなってちょっと思っちゃうんだよな。
これを意識しながら。
なんか人類に入らないというか、
もう多分もはや今Nexus 13の共通に、
みんなの共通認識な気がするけど、
なんかノリで使えるフレームワークではないんだなっていう。
素直に思っちゃったなっていう。
なんだろう、でも元々は割とノリで使える系だったよね。
元々はそうだと思う。
V11、V12、だから僕がもうちょっと仕事で座ってた時とかは、
そのSSRという自前実装したら吐くような仕組みを
利用者にやってくれるっていう部分だったけど、
近年はやっぱ暗黙的な、キャッシュ周りのやつもちょっとみんなめっちゃ叩いてたし、
このサーバーアクションズみたいな話もそうだし、
まあNexusは関係ないがサーバーサイドコンポーネンツみたいな話も。
で、だいぶなんか認知負荷が高いというか、
結構使い…なんか使うとしたら、
ちゃんとそのチームのコンテリビューターがみんなきちんとこれを理解…
これを含めたNext.jsの仕様っていうのを理解しないと、
結構罠を踏むんじゃないかなって個人的には思ったけど、
現場にいないんで、まあ適当なこと言ってるかもしれない。
今後のフロントエンドの行方
いやいや使えますよって話なのかもしれないし。
でもさ、なんか結構さ、
いやー、すり替わり早すぎてさ、
なんかどうせこれも1年後ぐらいにはなくなってるんでしょうみたいな気がする。
いやでもなんかそう…いや、なんか…
3、4年後前からそういう世界じゃなくなってると思うよ、フロントエンド版。
そうなのかな。
個人的には。
パラダイムとしてのその大枠の動きはこっちの方向に行くのかもしれないけど。
要はさ、1回作ったものをリプレイする間に、
何世代ぐらい時が進んでるんですかみたいな話だと思ってて、
要は世の中の大部分の人がこれを踏まずに、
次の世代からなんか書き始めるとか普通になんかありそうだなって思うし。
そうね。
その、今枯れたフロントエンドのコードを書きたいってなったらどうしたらいいの?
うーん、まぁ今だったらリアクトルーターじゃないですか。
リアクトルーターは枯れてるの?
うーん、まぁ枯れてるの定義次第かな。
別にネクストでもリアクトルーターでも個人的にはちゃんと使えれば、
そんなに別に賞味期限が短いフレームワークと思わないかな。
ていうかどっちかっていうと大事なのは、
リアクトに限らないけど、
フロントエンドで持ってるいろんな席も、
いかにバラしてモジュールとして資産として使い回せる形で持っておくかだけだと思ってて、
そのUIとロジックを分離するもそうだし、
そのロジックの中でもステータマネジメントとそうじゃない部分を分離しようとかさ。
だからレイヤーがあるわけだね、そのフロントエンドのアーキテクチャが。
一番そのユーザーフェイシングな部分は、
引っ掛けて簡単に置き換えられるようにしておけば、
そういうパラダイムシフトにもついていけるっていう感じかな。
リアクトなんてさ、別にコンポーネントはコンポーネントで、
どのフレームワークでも変わんないわけで、
それがフレームワークごとに変わっちゃってるんだったら、
それは多分コードが悪いと。
それで言うと、TSXとかJSX側にあんまり大きな変更って入ってないってこと?
そこで言うと、サーバーアクセドのコンポーネントとかは使うとなると、
難しいな表現が。
コードは書き換わんないけど、Next.jsとかの場合は、
ある種の最適化なのかな。
でも確かにコンポーネントっていう単位で言うと、そんなに変わんない気がするな。
JavaScriptの進化と変化
でも、サーバーコンポーネントとかは結構でかい変更だけど、
これが毎年あるかと言われたら全然そんなことなくて、
直近だとせいぜい3、4年に1回ぐらいなんじゃないかなって個人的な浅い観測の範囲では思うというか。
なるほどね。
10年前とかだったら確かに、マジで毎年コーヒースクリプトが死に、
なぜか大衆スクリプトが流星し、ビューゼイスリアクト戦争が始まり、
アンギュラムでバックボーンジェイスが死んだとか、毎年なんか死んでたけど、
ガルプとかも死んだよね、バベルも死んだっていうところやるかもしんないけど、
でもそこまでじゃなくなったかなって気はするな。
今のに毎年なんか死んではいるけど、
でもそのネクストジェイスみたいなやつが毎年出てきてるかというと、そうでもないし、
なんか、いや分かんない。
でもこの話な、そのフロントエンド以外の人と話すたびに思うけど、
多分感覚が麻痺してる部分はある気はするわ、自分が。
これについていけないなら無理じゃないみたいな気持ちもね。
ウェブパックはまだちゃんと健在?
健在だけど、ちょっと控えられてたかな。
ビートに押され気味だよね。
でもなんかビートもまたいなくなったりしそうだしな。
ビートはでも当分生きんじゃないかな。
RSパックとか、あとなんだっけ、もう1個ぐらいあったんだよな、その辺とはあるけど、
でもそれで言うとウェブパックは枯れてると思うよ。
逆にね。
枯れてる側に結構入るんじゃないかな。
てかさ、もはやさ、そのなんかNPM足りねーっつってヤーンができてさ、
最近PNPMとかもあったりするしさ。
もうそこすら落ち着かないじゃん。
まあでもヤーンなんてもう5年以上経ってんじゃないですか。
で、PNPMもまあ、なんか3年に1回のペースあったら頑張ろうって結果に。
もうなんかその感覚がさ、もうよく分かんなくて、その、いやー分かんねーなー。
ゴーモジュールスとかさ、ゴーだとゴーモジュールスっていうのが割と大きな変更だったけど、
でもゴーモジュールスが入ってからはもう全然、なんか、なんだ言ってるんだろうな、その、
それなりに大きい変更だったからこそ結構慎重に入れられてたイメージがあるし、
入ってからはそんなに大きな変更がないから、なんか別に、なんて言ったらいいんだろうな、
その、なんか、5、6年生き続けてる、そのゴーの、なんていうかその考え方みたいな部分が。
なんだろうねー、なんか。
標準パッケージで便利なものが増えたよーとか、
そのゴーの言語機能として便利なものが増えたよーみたいなのはあるんだけど、
別になんか、なくても動くし使えるしっていう感じであるし。
なんかそれで言うとさ、WebFrontEndがまだ実は借りてないとかなんじゃないかなって思う。
あーなるほどね。
そう、バックエンドはさ、いやー。
必要なものがある程度もう見通しついてるっていうのはあるかもね、確かに。
そう、で、言うてもほぼステートレスな世界でさ、
結構シンプルだし、なんか、僕はすごい、悪く捉えないでほしいけど、
なんかあんまりやることがあんないなと思っちゃってるんだよね、個人的には。
その、何の言語でもどれ使っても、その、GLPCだとHTTPだと、
まあグラフQLはちょっと、まあでも言うてなみたいな感じ。
まあHTTPが喋れて、なんか、
そう。
TypeScriptの重要性
あの、Aレス処理ができて、
そう、で、IOをちゃんと捌けて。
そうそうそうそう、要件がいくつか決まってて、
それさえ満たせれば別に何で書いても変わらんよねみたいな世界では確かにあるかもしれない。
どっちかっていうとなんかその組織論とかそれに紐づくアーキテクチャとか、
そっちのほうがやっぱその近年のトピックとしては熱いというか。
でもなんかフロントエンドはその、そうだね。
まあまずウェブの標準がさ、変わり続けてたらあるし、
その、JavaScriptが、
まあどうなんだろうな、成長過程という見方もできると思うし、
その、ウェブアプリケーション自体がどんどんリッチになっていってるみたいな話もあって、
そこに対して組織が追いついてきて、
じゃあなんかチーム開発、何人、何十人いじろうと思ったらしんどいじゃんみたいな新しいソリューションが出るとか、
あとは成熟していってコードベースがでかくなって、
ビルドがクソ遅いみたいな。
ウェブパックだともうビルドが10分かかりますみたいになって、
じゃあラストで書き直そうって話があったりとか。
直近だとTypeScriptのコンパイラもGoで書き換えたみたいなやつが出たんだけど、
そういうとこもあるし、TypeScriptのシェアがめっちゃ広がって左化していって、
なんかやっとだから2周目に入るみたいな。
なんかそういう部分がまだバックエンドとか他の領域ほど回りきってないみたいな感じなんじゃないかな。
でもそれで言うとそもそもなんかJavaScriptで足りないからTypeScriptがあって、
構造がもう特殊だよね。
まあそれはそうね。
まあそこはやっぱ得意性とか。
TypeScriptがさ、直接ブラウザで動けばさ、
そうだね。
いらんわけやんそこ。
なんかその、いやーおもろい。
その辺おもろくない?
いやーおもろいけどなんかさ、きついなーってちょっと思っちゃうな。
まあね、TypeScriptに至っても、
今ノードコマンドで動く世界になっちゃったからな。
うんうん。
でもあれもなんか、
いやーTypeScriptのパーサーもさ何個かあるんですよ今。
訳わかんないよね普通に。
TypeScriptの仕様は結構厳格なの。
いい質問っすね。
要は違うパーサーを使ったら、
違うコードが、
違う振る舞いをするコードが出てきちゃうみたいなの。
あったりしないの?
ないんじゃないかな。
なんかその結局TypeScript
特有の機能ってもうほぼ、ほぼないから今。
うん。
なんかその、ある種のアノテーションとして捉えると、
そのコンパイルっていう文脈においては、
バグってない限りは多分ないはずなんだけど、
どっちかというと型解釈とかの方。
型チェックの方で、
その仕様差みたいなのが出ちゃうとかはある。
可能性はあるんじゃないかな。
なるほどね。
ただ厳格な仕様は多分ないはず。
はずと言ってるのは、
ヒロッピーがPodcastでそう言ってたから、
その言葉を借りてるだけなんだけど。
その、言うてもそのさ、
エクマスクリプトじゃないから、
仕様を決めてコンパイルを実装してるわけじゃなくて、
TypeScriptチームがいいと思うのをガンガン継ぎ足して、
10年以上経ってるから、
仕様書になるものがないから、
実装が仕様ですっていう状態。
で、
それはさ、なんか、
ゴードを置き換えるみたいな。
よーやるよ。
それは本当にそうだね。
だからまあ、ボディなテストケースとか、
その巨大なOSSプロジェクトとかがあるから、
あるしそれでテストできるって話あると思ってて。
極論はさ、
Next.jsの巨大な、
リアクトの、
リアクタTSじゃないか。
その辺ビルドして、
アウトプットが完全に一致したら、
デグレはしてないよみたいな判定。
まあ100パーではないかもしれないけど、
できるよねとか。
そういう。
あとTypeScriptもなんかアップデートノート見てるとさ、
やっぱ、
あるんすよ微妙になんか。
その、
表現は難しいんだけど、
高型解釈され、
直感的にはどう考えても高型解釈されてほしいね、
っていう部分が、
今できてないけどそれができるようになりましたみたいなアップデートが、
やっぱり未だにちょこちょこ入ってくるからさ。
それがJavaがどうかみたいな。
それ壊れる?それによって壊れないの?
壊れはしないね。
逆にできるようになったことで壊れるケースって、
壊れるコードってないの?
ないかな基本的には。
ないの?
むしろ、
だからそういうのは、
結局TypeScriptってさ、
言語内容で言語ではないというか、
カターノテーションがついたJavaScriptでしかないから、
as anyとかでごまかせるし、
大体みんなそうしのいでると思うんですよ。
カタスイルムうまくいかないから、
でもコードは変えらんないじゃん。
カタに合わせてコードを変える。
スイルムに合わせてコードを変えるってわけわかんないから、
ある種のハックみたいなの、
わからんどみたいなみんなしのいでるところを、
わからんどなしでできるようになりましたみたいな話が大半なわけで。
そうTypeScriptの話、
フロントエンドの話をめっちゃしてしまったが。
いやーおもろいな。
そう、だから僕は結構重いな。
それでもJavaScriptに肩をつけたいんだなっていうのが、
個人的には気持ちで。
いやー、まあね、もう戻れないよ正直。
TSなしの世界には。
確かになんかPHPとか、
バックエンド開発の視点
なんかその、
語を書いてるとこからPHPの世界に戻ってくると、
もう超しんどいこと結構あって。
あーそうね。
タイプヒントあってもさーみたいな。
普通によくある話だし。
表現力がね。
PHPに至っては何タイムでしか選べないよね、確か。
コンパイルみたいな場合はないよね。
それも多分しんどいと思うし。
一応なんかリンタイみたいな感じで、
PHPスタンとかでチェックしてくれるから。
あーなるほどね。
だからある程度IDEがその辺はよしなにやってくれるというか、
PHPドック4でなんかしてくれる。
よくある話なんで。
確かに確かに。
PHPドックもそうだし、タイプヒントもそうだし。
タイプヒントより全然PHPドックの方が表現力があってみたいな。
あるある。
PHPドックなんか謎にリッチだよな、マジで。
謎にリッチ。
JavaのKFなのかな?
なんか語、そうだね。
語からなんかあそこに戻ってくるとやっぱ苦しいなと思ったから、
なんかタイプスクリプトという存在があることでだいぶ楽になる部分は、
それはそうなんだろうなとは思うが。
特になんかオブジェクト引き回すようなロジックが多い気がするから、
その辺のサポートがあるだけで段違いだなって気がする。
言うてフロントエンだとAPIのレスポンス受け取って、
その配列なのかオブジェクトなのかわかんないけど、
それに型がないってなるとさ、
プロパティが入ってるかどうかの保証もわからんまま引きずり回して、
そこをリファクターしてくれって言われた時に、
もう全部読むしかないみたいな世界なわけだから、
TSがないと。
一応PGPドック的なものもあるんだけど、
JavaScriptも書いてらんないんで。
なるほどね。
JavaScriptの特性
なんかでもGoはその辺うまく折り合いつけてる気がするんだよな。
コンテキストとかで結構いろいろ引き回したりするんだけど、
何かをコンテキストから引っ張り出してくる関数みたいなのが、
一個あれば事足りるというか、
それでなければそれで終わりだし。
そのコンテキストもあれだよね、
やっぱ1イテレーションがさ、
ステートレスに完結できるから、
めっちゃ強いっていうか、
コンセプト的に合ってる考え方なんて気がするよね。
最初に入り口はコンテキスト生えて、
で最終的にレスポンス返しておしまいで、
次はまた新しいコンテキストが生えて。
そうだね。
ほんでか、さっき言ったけど。
でもさっき言おうと思って言い忘れた気がするけど、
神田さんの中的には賛否両論は分かれるけど、
慣れると結構便利なんじゃないかっていうのは、
最後にコメントをくれていて。
でも触ってない僕がごちゃごちゃ言うより、
実際仕事で使ってるメンバーがそう言ってるっていう方が、
100倍説得力があるというか、
この意見はなるほどなと思ったんで。
まとみもそんな感じの印象ではあるから、
比較的素直な機能ではあるんだろうなとは思うな。
表向きというかその使い勝手のメンバーと。
そうだね。
でも裏は結構いろいろあってっていうのを出してくれてるっていう意味で、
そうだね。
良い記事かな。
雰囲気で使うから完全に出せる解像度だなって思ったな。
これ結構読んで理解してるの大変だと思うけどな。
リアクトもさ、みんな当たり前のようにJSX書いてるけど、
あれもコンパイルされてるわけじゃん。
それと一緒だと思えばまあまあ、
えーって感じで面白く読む。
知らんけど。
知らない。
いやー、読む記事。
いやー、フロントエンドやりてーなー。
こうやって話すとやっぱ好きなんだよなー。
この訳わからんさが。
なんかフロントエンドをやる仕事作るか。
そうねー。
なんかUI、謎のリッチなUI。
いやでもやっぱ謎のリッチなUI作るか。
なんか謎のリッチなUI作る機会意外とないんだよな。
いいじゃん。
ノーションから脱却して、
こう、ポッドキャストのページを作ればいいんじゃない?
ノーションもどき作るか頑張ってるやん。
ノーションもどきまでいかないといけない。
なんかその、なんか、リビルドFMってやつ。
あー、リビルドFM、そんなん。
リビルドFMはなんか、えー、どうやってんだろうね。
これでもさ、なんかあると思うんだよな。
なんかポッドキャストみんな似たような、こういう。
あ、そう。
いや、そんなことないか。
そういうのとか考えてるか。
んー、わからん。
わからんけど、チェイクエリーが古いことだけはわかる。
いやー、すぐわっぱらい。
まずわっぱらいだでしょ、こんなん。
こんなんすぐまずわっぱらいだでしょ。
チェイクエリー古い?NJXも古い?
やめやめよ、そんな。こんなん。
まずわっぱらい。
ただのポッドキャストに喧嘩のようなことはやめよ。
おー、面白いね。
まあ、こういうの作ろうよ。
確かにね、作るか。サイドプロジェクトに。
で、なんかパスキーが必要なようにしたい。
あー、確かにね。やろう。やりたい。
あ、しょうもねー。
で、クラウドフレアで。
いいね。
そう、AIがクロールしに来たら、お金を払えばサマーリング投票してあげますよ。
めっちゃいいね。やるか。
そうでなければ、ポッドキャストの音声を全部処理する必要がありますよ。
それで、じゃあ、今年いけるかな。頑張りたいな。
なんか、バックエンドとあれ分けようよ。
確かにね。
バックエンドやるよ。
おー、いいね。
でも、サーバーアクションズは使えなくなっちゃうね。
まあ、でも。
サーバーアクションズの中からフェッチするっていうのはできるのかな。
できるんじゃない?
そうだよね。だからまあ、大学なんとでもなる。
そりゃそうだよな、だって。
まあ、絶対はただのサーバーのプロセスだから。
なんか、OIDCの処理の中身全部この中にいたら無理だもんな。
そうねー。
ゴリゴリにヘビーな使い方できるかというと多分そんなことなくて、
どっちかというとモデルベースでクラットをやりたいですみたいなやつとか、
そういう使い方の方が綺麗だったり綺麗に使えたりするのかな、この辺は。
確かにね。
実際に試したいね。やっぱり素振りが必要なんだよな。
じゃあ、リプレイ.FMのウェブサイト、近日公開ということで。
頑張りましょう。一緒にやりますよ。
はい、じゃあそんな感じですか。
無駄にそれを置くリポジトリとか無駄に堅牢な設定にしよう。
ガチガチにするか。
ガチガチにしよう。
やっぱり一個作ろう、素振りを。
1人でいじってるリポジトリでガチガチにしてもしょうがなくってさ。
わかる。
そうそう。複数人いるから初めてみたいなところあるから。
ラボ環境のオーガニセーションあるからそこに置くかもしれないし。
確かにね。やりましょう。
じゃあ次回はみんなに集まって知ってないこと多いのって感じかな。
サイドプロジェクトの計画
いや、もうさ。
まあいいや。
世の中的にはまだこれからだからね、多分ね。
もっと減る?
もっと減る可能性あるよな。
まあね、まあまあいいっすよ。
マッチポンプで供給していきたいな。
そうだね。
はい。
じゃあそんな感じで、皆さん次回もお楽しみにしてください。
おやすみなさい。
おやすみなさい。
