00:08
ここら辺を触れようかって言ってた流れで言うと、次が5章ですね。 5章ですね。
5章こそバランスの話なんだよな。 そうですね。
早すぎる最適化 VS ホットパスの最適化っていうやつ。
で、早すぎる最適化っていうのは、あれですよね。そんなに使ってみる前に最適化とかチューニング頑張っても結局さ、みたいな話と。
で、ホットパスの最適化っていうのは、めちゃくちゃ叩かれる部分だったら最初からちゃんとしとこうぜ、みたいな。
出してから直そうじゃねえんだよ、みたいなやつですね。 そうですね。
まあ以上ですって感じに言われちゃうんだけど、まあそれはそうだねって以上って感じになっちゃうけど、
まあここでもいろいろどういうふうにそのトレードを見極めていきますかっていうような話をしてくれてますね。
ここらへんはじゃあ具体的にどうやって定量化するのみたいな話も踏み込まれてたそうでしたね。 そうですね。
またここでもパレートの法則が出てくるんですよね。 まあ大体そうですからね。
そうそう。世の中大体パレートの法則に従って物事はできてますから。
28どころじゃないですからね、たぶん。ウェブアプリとか。 そうそうそう。本当そうなんですよね。
イスコンとかやってるとそうなんですけど、結局よく叩かれるAPIをまず直さないと。
1個のAPIがすげえ遅いってわかってるんだけど、でもこれって1回しか叩かれないじゃん。
これとこれを最適化したところで他はボトルネックだから詰まっちゃうから、ここを直してもしょうがないよね。
今の段階だとここを直してもしょうがないよねっていうのはめちゃくちゃあるんで、本当にちゃんと計測したり、
どう使われてるんだっけとかどういうふうにユーザーに使わせたいんだっけっていうのはわかってないと、
検討違いのところを最適化して、こんなAPI早くなりましたとかっていうふうにやっちゃって、
いやでもユーザーの体験としてはめっちゃ悪いがとかいうふうになってしまうんですよね。
本は1回やっとくとマジでいいっすよね。
本当、早くしたのに全然スコアが上がらないっていう経験をすると、
あ、そうかこれじゃダメなんだっていうのがよくわかりますね。
ノーソンに僕が入れてるメモを見て、たすかにって思ったんですけど、
自分が書いたメモを見て自分で確かにっていうのは、なんという話だって感じですけど。
ここはもうリリースする前から、最初の実装時点からある程度やっとこうぜみたいな勘どころが、
やっぱり年数経ってくると、なんか自分の中でいくつか、いくつか、いくつも、ちょっとね出てきますよね。
出ますね。動機でやるか非動機でやるかとかって結構、
なんかこれ頑張れば動機でやってちょっと待たせちゃうけどみたいなやつもあったりするけど、
いやこれは絶対非動機っしょみたいなのとかは、なんか結構見極めがありそうだなって個人的には思ってますね。
03:03
あとこれは対して時間に対した処理コスト、まあ時間っていう意味で処理コストかからないけど、
ちょっと結合先がこれだからやっぱ切り離しとかかとか。
なんかデータ作るところはオフライン処理で回しておいて、それ参照させるかとか。
大げさに言えばその美しさみたいなものが、ちょっと自分の中で自分なりに入ってきたりする部分かなっていう気がしますね。
そうですね、そうですね。いやー、これを見ながら非動機でキャッシュを作るとかいっぱいやったなと思いながら、先にウォームアップしておいた方がいいなとか、
結局その負荷が、このユーザー数だったらまだいけるけどとか、その段階的に出していくタイミングではまだいいけど、
じゃあ全ユーザーが使ったらどうなるかなみたいなことを考えた時には、これ間に合わんなとか、じゃあウォームアップしよっかとか、やっぱ非動機に最初にしておいた方がいいよねとか、
いうのは、なんか社内のねお試しで何人かにちょっとこれこんな作ってみたけどどう?って見せる時は全然動機でいいなとか思いながら作って、
じゃあこれ全ユーザーに活用しようと思ったら無理だなとかって思って、それをじゃあちゃんと最適化しましょうみたいなことを考えたりとか、
まあその間いっぱいいっぱいいろんなことやったなという気はしますね。
なんかすんげーめちゃくちゃ笑ったのが、なんか僕が前行った会社の在籍期間かぶってないんですけど、
人がカンファレンスで登壇で発表して、なんかこういう機能があってこういう風な工夫をして処理早くしました的な発表してて、
でね、アスクザスピーカー行ってそれ作ったの僕なんですっていう話をして、すまんって言って、面白かった。
いいですね、作者の顔が見える。
金城さん〇〇っていう機能を多分知ってると思うんですけど、昔いたずらんでって言われて、知ってるっていうか、ちょっと一旦ギットブレイブしてみようかみたいな。
ありますね、ありますね。
あれはね、いやでもあれは確かに話を聞いて、まあ完全に俺が悪いわって思いましたね。それは遅くなるよなって思って。
何の工夫もしてませんでしたって思って。
いやーこの辺とかね。
ちょっとね、ちょっと土下座案件です。まあでもリリースできてるからな、別にサービス価値はしっかりしてるから、いいんですけど。
まあどれくらい。
サービスの価値も付加して、かつ雇用のニーズも作ったという意味で、いいんじゃないですかね。
レベルアップタスクとしてあったし、よしということに、そのどうにか弁明する人みたいな。
でもそうなんですよね、なんかデータ量が増えていった先でこういう問題が起きるよねって分かってるけど、
06:05
分かってたんだけど辞めてしまってそれが受け継がれないとかね、いろいろあったりしますからね。
いやーどう、最初から重かったんじゃないかなって思うんですけど、
まあでも処理に時間がかかってもいいっていう判断をしてる可能性もあるじゃないですか。
うん、ありますね。
どかしてるとかじゃなくて、なんでアレコードレビュー撮ってるんだろって言われなくて、後から思うと分かってないんであれなんですけど、
そんなに困らないというか、ユーザーのやりたいことは達成できていたっていう状況は成立しなくもないのかな、ちょっと聞くか今度会ったら。
まあね、非同期でやって動かしてて、別に次の日までに間に合ってればいいよみたいなやつとかで、
1時間だろうが2時間だろうが5時間だろうが、別に達成したい目的はうまくいってるからいいよねっていうのもあって、
ただ一方で計算資源はずっと使いっぱなしよりは短い時間の方がいいよねとか、
あとリトライするとかは短い時間の方がやりやすいよねとかいうのがあったりするから、
そういうところのトレードオフとかも多分考えないと、運用コスト的なところのやつもトレードオフの中に入ってくるよねとかいうのもあったりしますね。
そうですね、二酸化炭素の排出量とか意識しましょうって本にも書いてあったし。
この本に書いてありました?
いや、責任あるソフトウェアの方ですね。
この本ではトレードオフか、二酸化炭素を出しますか出さない手段を選びますかのトレードオフはありえるか。
いや、単純に見落としてたかもと思ってドキッとしたというだけです。
そこまで古式広げてる本ではない?
24時間かかるバッチとかを過去を見てリトライができなくて辛いなって思ったことがあったんで、いろんなものを思い出してきました。
確かにあったな、ローカルでバッチ回してデータだけ作ろうって思ったら週明けに会社行ったら落ちてんじゃんみたいな。
早すぎる最悪かっていうけど、ちゃんと作ったらちゃんと動くやろみたいな世界もあったりするんで、普通に作りましょうよみたいなこともあったりするんで、
作れるように頑張ってスキルを上げるって大事だったりしますね。
あとモニトリング最初から仕込んでおくかはやるようにはなりましたね、どっかのタイミングから。
大事です大事です。
バッチ処理とかはwebAPI、オンライン処理でもオフライン処理でもどっちでも別に処理にプロセスタイムみたいなものを出しておけば集計はできるんで、
遅くなったら考えようっていうのはどのタイミングのことですかっていうのだけ明確にできれば、それを知る術があればどうにかなるかなっていう気はするし、
09:12
逆に言うとデータが増えすぎた後だと、インデックスを後から付けようとかは辛くなりそうだなとかあるわけじゃないですか。
ありますね。
逆にデータがそんな増えないけど結構柔軟な検索というか、データ抽出されるぞってなった時に、
フルテーブルスターで十分持つか、キャッシュ機貸せればいいだけかとか、いろんな引き出しはある気がするんで。
そうですね。フェッチローズが10行だったら別にインデックスがあってもなくてもフルスキャンで足りるじゃんみたいなのが全然ありますからね。
そうそう、マイスチュールにせよポスグレにせよ早いですからね基本的には。
そう、てか今あれじゃないですか、ディスクがSSDだから下にあるのが早いんですよね。
別に昔のHDDじゃないからその辺とか全然あんまりちょっと変わっちゃったんですよね時代が。
一昔前だったらやっぱそれをキャッシュレディスに温めておきますかとかいろんなことを考えてたんですけど、
あれ別に普通にこのマイスケールってキーバリストアとして使えんじゃねえぐらいな感じのスピードである種使えたりするっちゃする部分もあると思うので。
そういう使い方をするっていうのも全然ありかもしれないとかね、いろいろ手はありますね。
そうですね、処理は重くなるけど別のところで工夫してユーザーを待たせることができるなとか、
ユーザーを待たせられるかもしれないけどそのリクエストが集中した時になんか引っ張られて他のところまで苦しくなるんだったらやっぱり対策しようぜとか。
楽する方法がいろいろあるといいですよね。今やった方が楽だったら今やるし。
そうそうそう。
今日仕事でインデックス張った方がいいかなってクロードに聞いたら、
いやここはプライマリーキーで引っ張るだけで十分なはずなんで大丈夫っすって言われて、本当に並べ替えないのって話をしてました。
ああ、怪しいですね。
でもですね、それは完全に論破されたんで大丈夫だったって。
良かった良かった。
じゃあ早いから十分だからって言ってnプラス1を放置してていいかって言ったら、それはなんか普通にちゃんとしといた方がいいぞみたいなのもいっぱいあるんで。
そういうちゃんとできるところはちゃんとしといた方がいいですねっていうのもありますね一方で。
そうですね、nが増えすぎちゃうと辛いからな。
頭打ちになってればある程度。
そうなんですよね。nが十分に小さいときは大抵のことはあんまり気にならないですからね。
12:00
けど大抵問題っていうのはnがでかくなったときに襲ってきて、なんであの時こうやってないんだよとか、なんでnプラス1になってんだよみたいなのをひたすら直すみたいなことだったりするんで、
そんなに複雑にならないんだったらちゃんと作っておいた方がいいぞって思いますね。
そうですね、ネタベースのリファクターとかめんどくさいからね。
本当そうです本当そうです本当そうです。
大体できなくないんですけど、なんかちっちゃくやってもめんどくさいなっていうのはやっぱりあるからな。
俺の設計ミスでサービスメンテナンスダウンタイム作らせるの申し訳ないみたいなのがあるんで。
そうなんですよそうなんですよ。
やっぱりアンデューできない非快逆なものはちょっとちょっと気合を入れてコストかけてやっといた方がいいですよね。
ティーワダさんのいう2wayドアってやつですね。
ティーワダさんが言ってたわけじゃないけどね。
そうなんですよね、だから結構設計レビューとかで見るときとか、これってソースコードレベルだったら言うたらもう書き直せばいいやみたいな。
こういう方針でもう一回やり直してよとかって言えるから、じゃあこれでチャレンジしてダメだったらもう一方の案にしようかとかって言えるんだけど、
データベースでデータが溜まり始めた時にはもうこれ顧客のデータが入ってるんでってなるとちょっと辛いんで、
データ量が少ない間はインデックスはパッと貼れるんだけども、データ量が大きくなってこれをインデックスを貼るには何時間かかりますかねとかって言われた時にはもう辛いんで、
そういうことは先にちょっと気にしておくといいよねっていうのはやっぱりありますよね。
インデックス貼っときましたって言われて、いやでも君これアプリケーション考えたらさ、ビトイン使うよねみたいな。
インデックス、途中のインデックス効かなくなるでしょみたいな。
そうなんだよ、インデックスがどういう風に効くのかとかどういうものなのか、B3でことを気にしておくとかもそうですね、必要だったりするし。
いっぱいいっぱいありますからね。
やっぱりそこらへんの知識、引き出しを増やしておくとか、どういうところがどういう風に成長していくのかなとか、成長した時にこういう影響出るよねとかっていう視野を広げておくと、
もしかしたら早すぎる最適化というか無駄なコスト払うのを避けられるかもしれないし、逆に言うとそれがわからないとおっかなびっくりになるというか、全部やらなきゃってなっちゃいすぎるかもしれないし。
15:01
逆に言うと計測してOKだったらやれるから、その計測とか予測を立てるための手段を持っておくといいよねとか。
予測の計測もできないんだったらロールバックの逃げ道だけ最初に用意して、飛び込むかとかありますからね。
本番をね、本番ワークロールを100%再現するっていうのはめちゃくちゃやっぱり大変だと思うので、どうにかしたい。
そうすると過去にいた経験としてこういうのをやったんだよね、が効いてくるから、やっぱり経験を積めるしかないんだよなってなるんだよな。
でもあれもあるじゃないですか、先輩がそうやっていい感じにガードレール作っちゃうと、何も知らない間に守られてて経験を積めないみたいなね。
本当それあるんだよな。本当それあるからなかなか難しいですね。
いろんなものを任せてもらうっていう必要もあるし、でも失敗すると取り返しがつかないなって思うと先輩がやっちゃって、
あれ?なんか俺が経験積みたいと思ったところ全部ないんだけどみたいなことになるんだよな。
その辺やっぱりどうしたらいいんだろうなって迷うし、今だとAIさんがこういう設計がいいと思ってますって言ってくれるのは多分出たし筋がいいこと言ってくれるっていうのはあるんだけど、
でも経験してないからなかなか本当にこれがいいのかどうかって確証を持って言いづらそうだなっていうのもあったりしますね。
いやー難しい。やっぱり若いうちにDB飛ばしておかないと。
そうね、やっぱ本番DBを飛ばしてからか。
やっぱり世間がどんどん厳しくなると本番データベースぶっ飛ばしづらくなるんで。
そう、やっぱね本番のデータを消してからが一人前とかね、画面を白くしてからが一人前とかってよく半分冗談半分本気で言ってますね。
飛ばしてほしくはないんだけども、でもそれをしてしまうぐらい経験をやるといろんなことを気にしないといけないってことが本当によくわかってくるから。
いやー難しいな。
難しいですね、だからまあ。
なんかあれじゃないですか、いや俺は中学の時は部活で先生に殴られて頑張ってたよとかっていうのと変わんないじゃないですか。
僕は別に殴られてないですけどね、ボールはみんなぶつけられてるんですけど殴られてはいない。
それはほぼ類似なのではみたいな思いながら。
人によっては蹴られてたとかありますね。
殴られてはないけど蹴られている。
18:00
まあまあだが業界が良い方向に行ったと捉えるのか失敗するチャンスが減っていると捉えるか、だから社内ツールとかで失敗しとくといいですよね。
社内ツール業界に運満リクエストこないからな。
大量のデータも積まれないからな。
そこなんだよな。
だからユーザーの見えないところで何か良い感じに失敗できるといいですね。
そうですね。本当に失敗しなくても覚えるでしょうということで。
じゃあ次に行きますか。我々はやっぱり喋れますね。
もう一個取り上げたらもうちょうどいいぐらいじゃないかっていうぐらいの時間になってきてますね。
ちょうど半分ぐらいなんだけどな今。
そうなんだよな。想定では半分なんだけど。もう時間的にあともう一本喋ったらちょうど良くなりそうって感じですね。
どこ行きますか次。
次行きますかね。
リトム回ってるってなると九床とかに行っちゃった方がいいかな。
九床行きますか。ここも話長くなりそうだな。
まあまあまあ。話なんて長くしたくなければしなければいけない。
九床はサードパーティーライブラリ。あなたが使うライブラリはあなたのコードとなるっていうところですね。
そうですね。
サブタイいるのかなっていう気はしたけどサブタイがないとよくわからないのか。
サードパーティーライブラリとしか言ってないですからね。タイトルが。
この章は何が言いたいかっていうと扉を読んでもいいしまとめを見てみてもいいのか。まとめ。まとめ長いな。
結構ね。結構長いですよね。
15個ぐらいある。要するに自分たちで作ったものじゃないよねっていうのがサードパーティーライブラリだと思うんですけど。
そうすると本当に100%120%自分たちの都合にあったものにはならないよねっていう前提があって。
さっき言った拡張性とかね。楽に言うとここまで複雑な使い方しなくてもなんかチャサッとやりたいのにみたいな時の煩わしさっていうのが出てくるかもしれないし。
自分たちでやりたいこととライブラリ自体が持っているものっていう折り合いをつける部分の。
じゃあテストってどうしましょうかって話も出てくるかもしれないし。
21:00
あとライフサイクルを管理してるのが自分たちじゃないので。
ライブラリバージョンを上げなきゃいけないけどよくわからない関係ないタイミングでバージョン上がってくるよねっていう時に。
安全にバージョンアップしていく。メンテナンスし続けていくっていうのはどうやろうかみたいな話とかで。
そこら辺を丸々と含めてあなたが使うライブラリはあなたのコードとなるっていう風に書いてあるかなという感想ですね。
そうですね。そうなんですよね。だから01って考えると全部自分たちで書くんやなのか。
多くのところはライブラリに任せるんだ。フレームワークに任せるんだって。
どっちかに言い切っちゃってもこの問題は全然解決しないから。
じゃあどこに落とし所を見つけますかっていうのは難しいですね。
昨今サプライチェーンアタックとかもあるし。
そうですね。それこそフレームワークの機能どこまで使うかみたいな話とかもありますからね。
20年以上言ってる気がするけど。
ずっと同じ話してる可能性が。
そうなんですよね。だからさっきバージョンが自分たちの都合とは関係なく上がってきてっていう話もあったけど、
逆もしっかりで自分たちの都合としては上がってほしいんだけどメンテされてないせいで上がってこないから使えなくなっちゃう。
じゃあこれどうするのみたいな。フォークするのみたいな話とかもやっぱあるし。
てなるとやっぱじゃあ自前でやるかって思うけど、
でも本当にこんなにいろんな機能あれこれ全部自前で用意してPHPのバージョンが上がったらバージョンアップに追々していきますって言うと、
それはそれでちょっと辛いねみたいなこともあるんで。
そうですね。サードパーティーライブラリーになると学習コスト低くなってもするじゃないですか。
はいはいそうですね。
モノログってみんな使ったことあるよねみたいな。
そうそうそうそうなんですよね。
だからその辺とかがじゃあロガー自分たち作るかって言われたらちょっとちょっとしんどいですね。
ロガー、そうですねロガー別に作れるんだろうけど作ろうって思ったことそんなにないよ実際。
ないし、じゃあファイルの管理を超厳重にやりますかとか、ローテートをやらないといけないよねとか、
あと多分PHPのモノログのロガー周りだとストリームのチャンネルとかを生やせるようになってるんで、
ファイルとスラッグとかってできるからその辺のインターフェースまで考えて実装しますかとか、
自分たちの都合を考えたらそこまではいらないけど、
24:00
いやでもこの後これ追加したいとかあるよなとかいろいろ考え出すと、
なんかそれを議論してるぐらいだったらコンポーターにモノログで入れた方がいいんじゃないみたいなことが起きかねないかなーって思ったりしますね。
まあそれで言うとPSR便利な、PSRロガーそんなに機能ないからあれだけど、
そうですねモノログとか使ってるとねチャンネルとかスコープ、スコープってモノログの概念でしたっけ?
あれフレーム?ララベルとかが勝手に言ってるだけか?
だからその辺がだんだんよくわかんなくなってくる。
どこまでが何かわかんない。
あるもんなカーボンなのかレートタイムインターフェースなのか、あ、モディファイってそっちだったんだみたいな。
そうそうそうそう、いや本当によくある。
まあでも複雑なことやるんだったら、枯れたというか完成度が高い高機能のやつ使おうねーになるから。
そうですね、でまあ我々としてこうよく2人とも書いてるのはやっぱ不廃防止装みたいなものを用意して、
直で使わないようにして、まあ最悪なんかあった時にこう切り替えできるようにするみたいなことを考えておきたいよねとか、
まあそうすることによってテストの時とかだいぶ楽になるよねとかっていうことは共通見解として思ってますね。
そうですね、まあアダプターとかドライバーとかパターンはあると思うんですけど。
というか、中間にゲートウェイ的にイスを挟んでおかないと、このライブラリの機能を全部使うぞ、うおーみたいな気合を感じてしまうじゃないですか。
うんうん、わかる。
使いたいAPIを絞っておきたいみたいな話もあって。
その不廃防止っていう目的もちろんあるんですけど、なんかそうじゃなくてもうちょい平らに使いたいからやれること少なくしてみたいな。
だってそうしないとMock作りずろうてずろうてみたいな話とかもあるし。
いやね、あちこち入荷するHTTPをされた時にはもう大変なわけじゃないですか。
そうなったらやっぱHTTPクライアントインターフェース経由でしたいよねとか、そもそもこのユーザーエージェントはこう名乗りたいからインスタンス作るとこはこう一箇所にしてとかってやっぱりやっときたいです
よねとか思ったりもしますし。
あとあんまり手で作らないと思うんですけどPSR7のリクエストとかレスポンスのオブジェクト、あれインターフェースから自分で作るとマジでめんどくさいんで、そんなに定義させるのかお前みたいな。
27:01
そんでもってセッションは入ってないんだよなみたいな。
そうなんか結構足りないっていう気持ちがすごいあるんだよな。
分かるんだけどね。
綺麗なんですけどセッション外したのがすごい素敵な設計判断だなと思うんですけど、だいたい使う。
そうなんだよななんかバージョンアップのこととかいろんなもの見据えてじゃあこれはPSRに依存してとかってやるとあれなんかこのメソッドないんだとかこれないんだとかってやるとこれはじゃあPSRじゃないもの
にやっぱり依存したいなっていうことになったりとかね、いろいろありますからね。
そうねコンテナインターフェースとかマジでかなり絞ってるしな。
そうですね、絞ってるからある種互換のものをパッとちょっと作ってみようかなってお遊びする意味ではねいろいろチャレンジしやすいからいいんですけどね。
あと腐敗防止のところさっきのMockとかStubとか作るの辛くないっていうところがララベルとかだとフェイクが用意されてたりとかしてそこも含めてライブラリーがフレーマーカー丸々用意してたりとかして、
これはすごいなということを感心しましたね自分は。
そこまで作り込むんだってちょっと思っちゃったりもしましたね。
あれば使って楽をできそうな部分は確かに多いよねって思いつつ。
いやでもちょっとテストコード見てしんどいなって思ったりとか、これバージョンアップでぶっ壊れるんじゃないかなとかって思ったりとかすると、いやなんかもっとあんまりそこに依存せず使おうぜとかって気持ち
になって、だんだんさっさと絞っていくとあれなんかこれララベルである意味あるんだっけみたいな気持ちになったりとかしたりとかして。
大体欲しいのってこれとこれとこれだからなみたいなことが大体はあるんでそれだけ使えればいいかなみたいな結論に落ち着くっちゃ落ち着くんですよね。
この辺がね本当にやっぱりフレームワークとかライブラリーとの距離感とかそのいい距離感と持つためにどこで何頑張りますかとかって話になってきますよね。
あとはそういう違反をどうやってチェックしますかみたいなところでいくと昨今であればPHPスタンダードだったりとかデプトラックとかいろんなものがツールが揃ってきてるからそういうものを使いながら違反を検知
するとかここは許可するけどこっちは許可しないみたいなところとかをちゃんとやっておくとコードレビューで全部指摘しなくても済むとか
人間が書いたドキュメントを他の人が読んでくれなくて守ってくれないんですよみたいなことを防げたりとかもするんでそうやってサードパーティーライブラリーに上手に依存しましょうっていうのは結構ありそうだなって
30:03
思いましたね。
あとはあれですかねこの本の中で出てた話で言うと菱形継承の話とかですか。
菱形継承。
継承じゃないか依存か。
菱形依存はねえっと12章の方にあるんですよねそこでは。
もっと先か。
そうもっと先で。
バージョンの話そっちか。
ちょっと関連してそこも一緒に喋っちゃうとあれですかね結局じゃあライブラリーに依存しますよって言ったけどAというライブラリーに依存してBというライブラリーにも依存してそのAとBがそれぞれまた違うライブ
ラリーに依存してってなったときにそこのバージョンの指定されているバージョンがうまく合わないときとかに大変なことになるからそういう辛さもあったりするよねっていうところはありますね。
ガズルがめちゃくちゃ互換性を破壊してきて大変だっていい話があってそれで生まれたのがいくつだっけPSRのクライアントインターフェースっていうのがそういう経緯で生まれてるんですよね確か。
そういう経緯だったんですよなんか自分はそこまでは知らなかったですね。
前田会社でテックブログを書くときにとりあえずPSRを深掘っていくと一定期間で書けるぞみたいなムーブをしてたんで。
PSR18httpクライアントでググるとちゃんと自分が書いたテックブログが出てきて便利。
すごい画像があふれてる。
これhttプラグ?httpプラグっていうのが昔あってこれをやってた人が確かPSR18書いてるんですけど。
ガズルの5から6に上げたときになんかすごい色々な互換性がガズルとしてはメジャーバージョンアップなんで互換性破壊してもいいじゃないですか。
ただこのPHP界隈でデファクトスタンダードになってるhttpクライアントがメジャーバージョンアップを上げたことによって
あっちは5.xに依存してるしこっちは6.xに切り替えてるしってなったときにPHPは同じクラスが1個しか存在できないので
これがですねだから5に依存しているライブラリと6に依存しているライブラリが同時に存在していると
33:00
それこそAWSのSDKとスラックのSDKをそれぞれ使ってますとかってなったときにバージョンが解決できなくなりうるみたいな
すごいありそうなシナリオがあって
めっちゃありそうつらい
ってなったときにフレームワークとかライブラリの相互運用のためのインターフェースあった方がいいよねってめちゃくちゃ真っ当なことを言って
PSRできてるっていう話がありますけど
これあれなんですよねASyncリクエストがPSR側にないから結局どうするみたいな話は出てそうな気がするな
みんなガゼルとかASyncリクエストのための別のインターフェース使ってないかみたいなやつがありきりですね
一方でこのPSRが出てきたことによってHTTP
PHP HTTPのディスカバリーってやつでHTTPクライアントは別にどれじゃないといけないよっていうのがない場合とかに
そのプロジェクトの中に入っているものを探してきてそれぞれをHTTPクライアントとして使うよっていうのがあったりとかもして
そういう何ていうか功績はあるといえばあるんでこういういいところもあったりするっていうのもあって
なるほどなと思ったりしますね
あれただライブラリー
PSR18の5巻ならいいのか
パッケージの名前決め打ちで探してるディスカバリー系の仕組みがあったんだよなと思って
しかしたらこれがあれかな実は中見たらそういうそういうもんかもしれないっていう可能性はありそうだな
昔そうだった気するけど今わからんすけどね
ちょっと中身まで全然読んでなくてそういうものが実はあるんだよって聞いてなるほどと思ったっていう
PHP HTTPディスカバリーパッケージのストラテジー空間の下にコモンクラシーズストラテジーっていうのがあるんですけど
ここ見るとなんか知ってる名前のクラスがレトロされているっていう
なるほど
ガズルストリームファクトリーとかリアクターストリームファクトリーとかスリムストリームファクトリーとかって決め打ちでよくあるパッケージの名前がレトロされてて
こいつをやるから探してきて見つかったらじゃあこいつを使いましょうっていう感じってことですね
そうですね納得感はなんでなんか自信のあるクライアントができたら多分ここにプルリクを入れて
俺も君のサークルに入れてよってドアを叩くみたいな取り組みが必要な気がするな
俺の考えた最強のHTTPクライアントを作ったからさ
36:01
これただパッケージコンポーザーかなタグ付けみたいな感じでPSRなんちゃらインプリメンテッドみたいなやつを宣言しておくと
なんか吉田にできた気がするんで本当にこれ必要なのだろうかってずっと思ってるんですけど
みんなね使ってますからねHTTPディスカバリーは必要なんでしょうね
やっぱ自分でちょっとしたHTTPクライアント実装したいなとか何かのAPIをコールするのをラップするやつを作りたいなと思ったときとかに
なんかあんま依存したくないなとか思ったときにはまあいいんだろうなと思いますけど
そんなちょっとしたものをみんなが使うわけじゃないから好きなクライアント選べばいいのではっていう話はあるかもしれないけど
でもこういうのがあると今後ある種拡張性みたいなところとかのことを考えたときにはいいかもしれないっていうのはありますね
そうですねこれはいいアイディアですよね
するとねやっぱり自分とコードとライブラリーのコードの距離感みたいなところはちゃんと距離をいい感じに保てるというところがあったりするから
少なくともガズレ5と6どっち使うかっていうのを自分で決定できるようになるんでねこれのおかげで
そうですね僕はガズレはちょっと依存したくないけどでも我々の顧客には使いたいという人がいるみたいになったときには
じゃあこれでお願いしますってやれば買わせるっていうところがありますね
でもこういうことを知ってなるほどこういう手があるんだってことを知っておくだけでやっぱできることがかなり増えますからね
そうですねまあそういう意味で言うとやっぱりOSSのコードリーディングとかしてると
こういう問題の解決方法があるんだなとか工夫があるんだなっていうのを知る機会増えるんでやっぱり良いですよね
そうですね完全に一番カンファレンスに行ってこういうのがあってですねって言って
なるほどなるほどつっておもろしろみたいな感じで教えてもらったから
カンファレンスとかに行くと自分の知らないライブラリーいっぱい知れるなって思ってますね
そうですねまあでも通称もそんな感じかな
うんうんはいもう2時間近く喋ってますね
触れときたいものがありますあとこれは