柔軟性と複雑性のトレードオフ
リスナーのみなさん、こんにちは。London Tech TalkのKen Wagatsumaです。
本日もBookClubの感想会をやっていこうと思います。
本日はゲストとして、Keisukeさんをお呼びしています。
Keisukeさん、今日もよろしくお願いします。
よろしくお願いします。Keisukeです。
よろしくお願いします。
東京でITエンジニアをやっております。よろしくお願いします。
よろしくお願いします。
Keisukeさん、ゲスト初出演ということで、今回はBookClubの第4章です。
章のタイトルがBalancing flexibility and complexityという章の感想会をやっていこうと思います。
Keisukeさんは、London Tech TalkのBookClubとしては2冊目になっていて、
この2冊目のSMaTのほうから参加してくださっているということで、
初めにどうしてBookClubに参加しようと思ったのかというのを聞いてみたいと思います。
今回のSMaTのほうから参加してくださる方が3人新しくいらっしゃるんですけども、
Keisukeさんはそのうちの1人ということで、
どこでこれを、多分Podcastで知ってくださったのかなと思うんですけど、
参加しようと思ったきっかけというのをお伺いしてもよろしいですか。
もともとPodcast自体はLondon Tech Talkのリスナーでずっと1年ぐらい、1年以上聞いてまして、
どうやってBookClubをやってるっていうことをもちろん聞いてて知りまして、
自分自身技術書を読む頻度が減ってきたなと感じていて、
初学者の頃はガシガシ読んでたんですけれど、
なんかちょっと業務とかに慣れてきて若干距離が遠ざかっていたので、
こういうBookClubに入ることで、ちょっと強制的に自分を奮い立たせようと思い参加しました。
いやー、それめちゃくちゃわかりますね。
なんか仕事慣れてきちゃうと、
初学者の頃のういういしかった自分の頃を忘れてというか、
最初の頃は本屋にいて、手当たり次第に買って何でも読んでたりしたんですけど、
外部からの刺激というか、一緒に勉強してくれる人のモチベーション駆動っていうのがすごい重要だなっていうのは僕も感じているところで、
もう一つは1年以上ポッドキャストを聞いてくださっているということで、
すごいありがとうございますという感じで。
結構嬉しいですね。
元々リスナーの方がBookClubに来てゲストになっちゃうっていうこの流れが個人的には大好きなので、
嬉しいですね。
じゃあ今回はSMARTという本を選んだんですけども、
この本を特別読もうと思った理由とかって何かありますか?
BookClubにまずは参加しようというモチベーションの方が大きかった感じですか?
このBookClubに参加したいというモチベーションもあったのと同時に、
この本自体興味があって、
本にも興味があるし、BookClubにも興味があるっていう2つで、
今しかないって感じでした。
タイミングがちょうどあったということですね。
ちなみにですけど、
積読してて読みたいけど読めてない本とかってあったりしますか?
他に同じタイミングで気になっている本とか。
積読というか、ちょっと最初の2、3章つまみ食いして放置してるみたいな本はたくさんありますね。
何でしょうか、声は。
タイトル思いつくのあります?
僕もそういうの結構いっぱいあるんですけどね。
そうですね。
今後のBookClubの参考になるかなと思って。
例えば、
SystemDの思想と機能っていう本を読んできましたね。
それ知らないですね。
あとは、
まだ読んでる途中なんですけど、
Architecture and Design of the Linux Storage Stackっていう本もありまして、
それも読んでました。
Linux KernelとかLinux Distributionとか、
そういうトピックがわりと個人的に興味範囲なので、
そのあたりの話を、
本を結構読んでます。
読んでましたね。
めっちゃいいですね。
僕そこら辺もちゃんと定期的にキャッチアップしていかなきゃいけない分野だなと思うし、
SREとして働いてても時々あるんですよね。
なんかKernelのバグキーンのやつとか、
Linuxを深く知らないと解けないようなインシデントとかがあったりして。
けすきさんも第4回のブッククラブだったか第6回か忘れちゃったけど、
なんか気になるキーワードがありますということで、
eBPFの話とかでもちょっと盛り上がったりしましたよね。
はい。
それでいうと、
それは全部読んだんですけど、
Learning eBPFっていう、
日本語訳だと入門eBPFっていう本を結構前に、
英語版のやつを読みまして、
そうですね、eBPFは個人的に面白い技術だなと思っていて、
OSSのコードを読んでみたり、動かしてみたり、
自分でも書いてみたりみたいなことはしてます。
いいですね。eBPFもフィーチャー会したいですね。
著者の名前を。
リズライス。
ブレンダー・グレック先生が違うかな。
Learning eBPFはリズライスが書いたんですけど、
ブレンダー・グレックもeBPFコミュニティにすごいコントリビュートしてる方ですね。
元ネットフリックスですよね。
はい。今インテルでしたっけ。
インテルに入ったっていう。
リズライスさんってあれでしたっけ、
コンテナのセキュリティ系の企業でアンバサダーみたいな感じで活躍した女性エンジニアの方だったっけ。
そうですね。アイソバレントって会社で、
確かオープンソースのCなんとかOのオープンソース版みたいなやつ。
なんていう正式名詞か忘れちゃいましたけど。
それでかなりオープンソースとか、
あとカンファレンスでもよく発表されてるイメージです。
そう、eBPF関連のカンファレンスに行くと大抵顔が出てくるっていう、
すごいアンバサダー感があるすごい方ですね。
そっか、その方の本は僕読んでなかった。
なるほど、そこら辺に興味があります。
彼女のカンファレンスでコンテナを1から作ってみる、5で書いてみるみたいな、
すごくシンプルなコンテナランタイムを作ってみるみたいなカンファレンスがあって、
それを見てすごく面白いなと思って借機をした記憶があります。
それライブコーディングスタイルみたいな感じ?
そうですね、VSコードをカンファレンスの会場に移していて、
それに対して解説しながらコードを書いて、
それがGitHubのレポジトリにも上がっていて、
僕はそのレポを見ながらちょっと順番でも書いたみたいな記憶があります。
めちゃくちゃかっこいいですね。
ライブコーディングをカンファレンスするってなかなかハードルが高いんで、
そこにチャレンジしてる人普通に尊敬しますね。
すごいな。
すごいですよね。
ちなみにそのブッククラブ自体は、
例えば社内とか過去にいろんなブッククラブに参加したこととかってありますか?
前職では臨読会っていう形でいろんな本読みましたけど、
最近はずっとやってなかったので、
このブッククラブが久々です。
ちなみに今回のロンドテックトーク、
いろんなブッククラブのフォーマットがあると思うんですけれども、
実際に僕らのブッククラブのフォーマットとか参加してみて感じた雰囲気とか印象って何かあったりしますか?
前職でのブッククラブと比べてという形でもいいですし。
形式は同じかなと思っていて、
各回1章ずつ取り上げて、
一人一人思ったことっていうのを書いてみんなに共有していって、
共有されている内容で気になることがあったら質問したり、
今の形式と変わらないかなと思います。
いいですね。
結構読書メモとかもけいすけさんもしっかり書いてくれて、
それを読みながら、
結構Kubernetes周りとか、
それこそLinux、Python周りとかを書いてくれて、
そこら辺僕があんまり得意じゃない領域だったりするので、
いつも読書メモ楽しく読んでいるんですけれども、
今回の章の内容に徐々に入っていこうかなと思います。
Hooks APIの紹介
今回はバランシングフレキシビリティ&コンプレックシティということで、
第4章なんですね。
この本は全体を通して最初結構ソフトウェアプログラマー向けというか、
コードをアーキテクトするアプリケーションレイヤーレベルの話が結構多くて、
徐々にメモリの話とか、
ディストリビューティッド分散システム設計みたいなのに
移っていくんですけど、
この4章は割とまだアプリケーションを書く、
実装するという側面で、
インターフェースをどうきれいにトレードオフを考慮しながら
実装していくかという章だったと記憶してますね。
ここで結構キーワードとして出てきたのが、
実際に具体例としては、
メトリクスを収集するフレームワークをJavaで書くとしたときに、
どうやって保守性を損なわないように
拡張性を持たせていくかということで、
2つの形式が紹介されていました。
1つ目がHooks APIという形で、
Hooks APIみたいなのをユーザーに提供することで、
メトリクスのフレームワークを拡張していく。
2つ目がリスナーAPIという形で、
Hooksはちょっと違う形で、リスナー形式を使っても
フレームワークをうまく拡張できる手段を
ユーザーに与えることができるということで、
僕の印象はそうですね、
Hooks APIとリスナーAPIの実際のコード例を紹介しながら、
フレームワークとかOSSのライブラリを作る側の観点に沿って
拡張性をユーザーに提供していくような
コードの断片を紹介していくような、
そんな章だったかなと記憶してます。
けいすけさん的には今回の章を読んで、
リスナーAPIの紹介
ざっくりまずは記憶に残っているキーワードとか
感想をお聞きしてみたいんですけども、
けいすけさん的には今回の第4章を読んでみて、
どうでしたか?
はい。
柔軟性VS複雑性っていうところが
大きなキーワードかなと思っていて、
柔軟性が高いとユーザーはやりたいことを実現できるので、
嬉しい反面、メンテナーとしてはコードが複雑になって、
コードのオーナーはメンテナンスがしづらいみたいな、
そこのトレードオフが書かれているなと思ってます。
そこが一番自分に残ったところで、
正解はないトピックだと思うんですけれど、
そうですね。
このトピックを見たときに、
拡張性アタイル具体例フックAPIみたいなのが紹介されていたんですけれど、
そこでKubernetesのアドミッションコントローラーのことを思い出しまして、
Pod作成のプロセスにブックして、
例えばユーザー定義のプログラムでPodの内容をバリデーションしたり、
もしくは中身を変えてしまってPodに必要なセットアップを自動化したり
みたいなことに疲れているKubernetesの機能があると思っていて、
そこにそれを思い出しました。
なるほど。
このアドミッションコントローラーレファレンスについて、
もうちょっと詳しく教えてもらいたいんですけど、
これってAPIとしては、
基本的にはYAMLで全部表現できる形であったんですか?
CRDみたいなコードを書いたりとかもしなくていい?
基本的にはYAMLで全部定義できる?
アドミッションコントローラーの実装自体は、
アプリケーションのロジックとして存在していて、
アドミッションコントローラーのクライアントみたいなものが存在しまして、
KubernetesのAPIサーバーがPodを作成するっていうイベント、
アドミッションコントローラーを実装したクライアントに伝えて、
クライアントがこのPodの中に、
例えば新しいボリュームマウントをしますとか、
あとは環境変数を追加するとか、
あとはセキュリティ的にコンテナのケーパービリティとか、
不要なものが付いていたら、
それはセキュリティ的に危ないので、
このPodは作成できませんっていうように拒否したりとか、
そういうイメージでして、
ユーザーとしてはPodを作るときにYAMLを書くと思うんですけど、
YAMLをデプロイしたら、
最終的に出来上がるPodのマニフェスト、
YAMLとアドミッションコントローラー
YAMLで表現されるマニフェストと、
手元で実行したYAMLっていうのはちょっと異なる、
アドミッションコントローラーのステップを経て変わる、
もしくはバリデーションに失敗したら作成できないので、
デプロイできないみたいな感じと認識しております。
なるほど、そうかそうか。
だからKubernetes自体は結構いろいろリコンシテーションループとか複雑なことをやっている中で、
ユーザーがそれのイベントとかどのステップで何が起きたかっていうのに応じて、
例えばカスタマーアプリケーションを変えたりとかツールを書くときに、
Kubernetes自体にコードをハックしに行かなくても、
このアドミッションコントローラーのAPIを使うことで拡張性を与えることができるっていう形なんですかね。
そうですね。
KubernetesAPI本体のコードを変えなくても、
自分たちで定義したプログラムでその一人をインターセプトできるっていう拡張性を与えているのが
アドミッションコントローラーだと理解しています。
確かに確かに。
ミューテーションとか結構コンフィギュレーションの自動化とかそこら辺にも使えそうだし。
一方でKubernetesの他のAPIでもしご存知だったら聞いてみたいんですけど、
リスナーAPI的なインターフェースとかもあったりするんですかね。
Fux APIっていうのはいろいろステップがある中で、
このステップでどういったコードを実行したいっていうのを
フックするような感じで差し込む感じだと思うんですけど、
リスナーAPIは僕の本を読んだイメージだと、
ストリームデータカフカみたいなストリームデータサービスをリスナーというかコンシューマーを作るみたいな感じで、
何かイベントをKubernetesとかサブジェクトが発行して、
それをリスンするリスナーみたいな、
オブザーバーとかリスナーとかコンシューマーを作って、
そのイベントに応じて何か好きな拡張コードを書くみたいな感じなんですけど、
もしご存知であればそういったものもあったりするんですかね。
ぱっと思いついたりします?
はい、その前にBOOKCLUBで、
KubernetesAPIの拡張性
僕がリスナーとフックAPIの違いがよくわからないっていう風に言ったら、
そのBOOKCLUBの参加者が、
フックAPIは同期的であって、
リスナーAPIは非同期的であるっていうすごく大きな違いがあるよっていう風に解説をいただいて、
そこでリスナーAPIの具体例が、
僕の中で思いついたのが、
例えばメール送信のSaaSとかに対して、
確かに非同期だ。
例えばスラック通知とかも、
多分スラックにメッセージの内容をポストして、
スラックが通知したっていう完了は待たないと思うんですね、
そのアプリケーションがあって、
メールも同じようで、
なので通知系のセンダーグリッドとかスラックとか、
そういったSaaSにインテグレーションするときのAPIっていうのはリスナーAPIなのかなと理解してます。
確かに確かに。
そうだ、その話ありましたね。
僕もこれ分かった気になってスルーするところ、
確かケンタ君だったかな。
このSyncとはSyncじゃないみたいなことを言ってくれて、
なるほどっていうのをみんなで共感した覚えがありますが、
こういうところも結構ブッククラブのいいところというか、
自分の分かってないところを直してくれる人がいるっていうのが良かったですね。
確かに確かに。
確かそのね、議論の中で、
eBPFもまさにhookAPIみたいな感じかもね、
みたいなケスケさんもコメントしてたりしますね。
その後他の方の読書ノートを添いながらみんなで議論していった感じですね。
ケスケさんもし他の方の意見とかキーワードとかで印象に残っているものがあったらぜひ聞いてみたいんですけど、
今回はやっぱりそのアプリケーションを書いている側の人、
フロントエンドエンジニアの方もいればバックエンドエンジニアの方もいるので、
結構皆さん自分のその業務での経験とか、
普段感じていることから結構深い議論ができたんじゃないかなと思いますし、
友人さんみたいなそれこそフレームワークをね、
パブリックにオープンソースとして作っていらっしゃる方もいるので、
顧客が本当に必要なものと、
あと自分たちが実装したいものとっていう、
狭間で結構悩んでいる方もいる中で、
すごい面白い議論になったかなと思います。
ケスケさんの中で他の方の意見とかトピックとかで印象に残って、
ここで挙げたいものとかって何かあったりしますか。
ケンタさんのコメントで、
フィーチャーフラグとセキュリティリスク
本質的にはアウトソーシングっていうコメントが印象に残っていて、
拡張性を与えてクライアントアプリケーションがいろんなことできる、
つまりそれはクライアント側に複雑性を押し付けているだけだっていうような意見だったと思っていて、
システム全体でサーバーとクライアントを含めたシステム全体で見たときに、
複雑性は別に全体としては変わっておらず、
その場所が移動しているだけっていうのが個人的にキーワードで残ってますね。
これね、太字になってるしね。
これ誰が太字にしたんだろう。
これめちゃくちゃ記憶に残ってます、僕も。
この本の中では語られてなかったんだけど、
やっぱりその本質的にはアウトソーシングだよねっていう観点に立つと、
アウトソーシングした先の人が会社の中でどういうポジションにいるかっていうのが結構ポイントになってくると思うんですよ。
例えば同じチームの人なのか、もしくはチームを跨いだ先の人なのか、
跨いだ先のチームだったら同じマネージャーというかレポートラインが一緒なのかどうかとかによって結構コミュニケーションコストにも違いが出てくると思うんですよね。
例えばアウトソーシングした先が未来の自分とか同じチームメンバーであれば、
そんなにコミュニケーションコストって発生しないと思うんですけど、
例えばレポートラインが違う別の会社、タイムゾーンを超えた別のチームだったりとか、
それこそ顧客とクライアント、自分たちと顧客みたいな関係性だったり、
会社外のオープンソースとかになってくると結構コミュニケーションコストが出てくるんで、
だからこそインターフェースでどこまで表現するかっていうのは、
これはなかなかトレードオフというか難しい、
終わりのつきな議論かなと僕もこのキーワードを聞いて思ったことがありますね。
複雑性を押し付ける先、押し付けるって言うと音は悪いですけど、
複雑性をオーナーシップを持ってくれるチームっていうのが、
そうですよね、レポートライン違うかどうかとか、
もしくはお客さんかもしれないしっていうのはすごく重要な観点ですよね。
自分たちでライブラリを作るとかにしても、
複雑性を自分たちで管理することでお金をもらってるみたいなのが、
例えば僕が昔いたデータベースをクラウド提供する、
データベースアザサービスの会社だったりすると思うんですよね。
例えば僕はグラフデータベースの会社にいて、
グラフデータベースを運用するという複雑性を全部担うのでお金ください、
その代わりインターフェース、簡単なインターフェース提供しますよみたいなところだったりして、
SaaSとかプラットフォームアザサービスとかもそういうインターフェースになりがちだと思うんですけども、
ここで一つ議論してみたいのが、そこの複雑性っていうのが一つあるのが、
例えばプロダクトを作る側は複雑性を考慮してインターフェースとして顧客に提供するけど、
必ず顧客の中でもうちょっと拡張してほしいであったり、
もうちょっと自分たちにカスタマイズした機能を加えたいっていう人は必ず出てくると思うんですよね。
例えばそれがエンタープライズみたいな大きい顧客とかであったりすると、
どうしても声を聞かざるを得ないみたいなプレッシャーとかも出てきたりして、
そうなってきたときに現場のエンジニアとしてできることはなかなか少なかったりするようなシチュエーションもあったりすると思うんですけど、
そういったダイナミズムを普段感じて働いてるかどうかみたいなのが結構大きいと思うんですけど、
なんかそういうシチュエーションに出会ったことってあったりします?
あります。
声の大きいお客さんっていうか、要するに売り上げが大きい、
よく使ってくれてるお客さんになるとどうしても対応せざるを得ないとかあると思っていて、
基本的には今ある機能でどうにかならないかっていうのをまず、
なんで今だとダメなのかっていうところを議論していって、
どうしてもダメだっていうときにそのフィーチャーリクエストに対応するっていうことになると思うんですけれど、
そうするとフラグみたいなのがいっぱいできると、
コード内にフラグがたくさんできるとすごく複雑だと思っていて、
ですよね。
なのでその問題ってどの組織にでもあると思っているんですけれど、
めちゃくちゃわかる。
個人的にフィーチャーフラグの、
フィーチャーフラグっていうプラクティスっていうんですかね、
例えばあるお客さんの会社、
ユーザーを識別できるIDみたいなものを渡して、
そのお客さんがこの機能を使えるかどうかっていう、
ブーリアンを返すっていう、
そういうサービス、
それはもしかしたらHTTPのAPIかもしれないし、
ファイルに書いた設定かもしれないですけれど、
そういうフィーチャーフラグっていうプラクティスがあると思っていて、
それを使うしかないなと個人的に、
それ以外のソリューションが個人的には見当たらないなと思っています。
それめちゃくちゃわかります。
僕の過去の所属企業ではフィーチャーフラグは内製しているところが多かったですけれども、
フィーチャーフラグアザーサービスもあります。
確かプラットフォームアザーサービスみたいな。
名前忘れちゃった。
Launch Darklyっていう名前かなと。
有名なところだと。
僕はそこしかちょっとわからないんですけれど、
そういうサースも最近出てきているので、
確かにもうそのプラクティスは多分世の中にどんどん浸透していってるのかなって、
個人的に感じていました。
サービスになるぐらいだからみんな困ってるってことなんでしょうね。
そうですよね。
結構SRE観点とかだと難しいんですよね。
自分、エラーレートが跳ねたときにコードを見に行ったり、
システムを見に行ったりするときに、
そのフィーチャーフラグによって起こってるかどうかでも結構デバッグの、
最初の仮説決めって結構変わってきちゃうりするし、
やっぱりうちみたいな大きい会社だとフィーチャーフラグの名前はわかっても、
フィーチャーフラグ自体が何をしているかっていうのはさっぱりわかんない。
だからそのオーナーに結局ページしてそいつを呼ばなきゃわからない、
先に進めないみたいなシチュエーションとかもあったりするので、
僕らにできることはフィーチャーフラグの名前を特定して
ロールバックするだけみたいな形になったりはすると思うんですけど、
そこは難しいですよね。
はい。
あともう一つケースケさんのコメントで確かになと思ったのが、
拡張性を悪用されると脆弱性になると思ったとも書いてて、
ここのセキュリティリスクみたいなのもすごい納得しましたね。
だから何を拡張できるようにインターフェースを公開するかっていうのを考えるときに、
考えることはもう無限にあるなと思ってて、
将来の自分たちのメンテナンスコストもそうだし、
そのAPIを拡張することでその顧客が本当に達成したかったことができますかっていうのもあるし、
将来の増える顧客のことも考えてそれをカバーできるかっていうのもあるし、
さらにこのセキュリティというか自分たちが運用しているツールに
マイナスのネガティブな印象を与えないかというところも考えなきゃいけないということで、
一章で語られてますけど、なかなか深いトピックだなと思いますね。
このセキュリティ脆弱性に関しては何か追加のコメントとかありますか。
そうですね。
難しいですよね、これからへん。
難しいんですけれど、
例えばディモートにのプログラムを実行できるような拡張性を持たせちゃうと、
便利かもしれないですけど、
第4章バランシング・フレキシビリティ&コンプレキシティの感想会
それはそのプログラムのできることできないことをはっきり決めないともちろん脆弱性になりますし、
コンテナとかもそういう、もともとコンテナってかなり
任意のプログラムが実行できると思うんでコンテナ内では。
コンテナに対してどうやってセキュリティにするかってすごいずっと議論されているトピックだと思っていて、
そうですね。
そういうのもこの章を読んで思い浮かべてました。
確かに。
もしかしたらこのセキュリティという観点で深掘りをするなら、
例えばそれこそEBPFとか、あとWasmとかWebAssemblyモジュールですね。
あとは最近エッジでランタイムを動かすみたいな、
例えばCloudflare WorkersとかFastlyとかCDNも出してるし、
エッジで何か動かすみたいなところで結構制限をかけたりするようなセキュリティモデルとかからも参考になるものがあったりするかもしれないですね。
このセキュリティフィーチャー界っていうのも一回やってみたいな。
なかなか難しい。
そうですよね。
そうですよね。便利だと思って作ってた機能が、
セキュリティ専門家から見たらもう穴だらけみたいなことって多分あると思うんです。
そうなんですよね。
あともう一つ聞いてみたいのが、今回の第4章を読んで、
仕事に活かせそうなキーワード、もしくはもうすでに活かしたような何か内容はありますかということを聞いてみたいんですけど、
僕の場合、業務柄はそんなにオープンソースのライブラリをガリガリ書いたりとかっていうことはなくて、
どっちかというと他人が書いたコードをデバッグするときに読みに行くっていう、
障害対応してるのでそういうことが多かったりするんですけれども、
社内のソースコードを見に行くときとかに、
すっごいスパゲッティコースとかを見つけたりしたときに、
何か障害の後のアクションアイテムを再発防止策をみんなで考えるときとかに、
こういったものを提案できるかなというのも一つあるし、
個人趣味開発レベルでいうと、
ちょっとしたGitHub Actionのツールを書いたりだとかするときに、
コンフィギュレーションのインターフェースで、
どこまで何をユーザーに提供するかっていうところを考えるときに、
一つフックスAPIとリスナーAPIというメンタルモデルというか考え方の一つ、
キーワードの一つは得ることができたかなとか思ったりしますね。
外部のAPIを使うときに、それこそけいすけさんが挙げてくれたような
KubernetesのAPIもそうですし、
これはどっちの型なのかなというか、
どういったことが表現できるのかなという観点も、
新しく学べたかなとかは思いますね。
けいすけさんは何かありますか、
仕事に活かせそうな内容やキーワード。
そうですね。
1個メンタルモデルができたっていうのは大きいと、
フックかリスナーかっていうので、
新しいシステムを見るときに、
これはどういう思想の元、
どういうメンタルモデルというか、
どういうアーキテクチャーの元を作ったのかみたいなのが、
フックかリスナーかみたいな大きく、
ここではフックを使っているし、
ここではリスナーを使っているみたいな、
そういう、なんていうんですかね、
今までなんとなくここって似たようなコードになっているなとか、
似たような机になっているなっていうところに名前が付けられるっていうのは
結構いいなと思いました。
そうですよね。
他人と議論するときにもキーワードをベースに話していたほうが
最初の説明するオーバーヘッドとかも少ないですしね。
そうですよね。
ここはフックAPIだよとか、
フックAPIのように作ってみようかとか、
そんな風にコミュニケーションできると楽ですもんね。
そうですよね。
あとその拡張性の広げ方も、
これはけんたくんのコメントなんですけど、
その拡張性を渡さないのバイナリではなくて、
徐々に拡張性を増やしていくっていうところも
プラクティカルな現場ではすごい大事な観点かなと思っていて、
最初にいきなりバッと拡張させる。
例えば、JavaScriptが実行できる環境を提供しているとしたときに、
Evalが使えますみたいな。
文字列を渡すとそれがJavaScript提供できるみたいな。
それを最初からEvalでできますみたいなのって
かなりセキュリティリスクとかもあると思うんで、
最初は最小限の拡張性をまずは作って、
それをパブリックにオープンにすると。
ユーザー層の拡大とかフィードバックを基に、
徐々に拡張性を増やしていく。
そのときにトレードオフのバランスを議論していくっていうほうが、
拡張性をオープンにするしないっていうのは、
01のバイナリじゃないなっていうのも
1つ個人的には言語化できた観点だったりして、
すごい良かったなと思います。
毎度のことですけど、本自体より他人の、
他の人の書いた読書メモから学ぶことが多いっていうのが、
個人的に運営してて良かったなということですね。
とはいえまだ4章なんで、
なかなかこれからも面白い章が迫ってきてるかなと思っています。
後半のMOOCクラブに関して楽しみにしてる章とか目標、
意気込み的なのがもし何かあったら聞いてみたいなと思ってるんですけど、
今回の本は僕も最初にメンションした通り、
後半に行くに従って分散システムでのアーキテクチャとか、
メモリに置くかディスクに置くかみたいな、
データローカリティーの話とか、
僕が好きな領域になってくので、
個人的には楽しみにしてはいるんですけど、
けいすけさん的に後半に向けて何かありますか?
そうですね。
どんどん話の規模が大きくなるという。
特に具体的な思いとかはないですが、
みんなの意見を聞いて、
自分の意見を話して、
分からないところはどんどんオープンにして、
自分が分からなかったことはオープンにして、
身になればいいなと思いました。
そうですよね。
この時に確かけいすけさんが言ってくださったのかな。
自分が分からなかった内容をシェアした方が、
学びになるみたいなことを言ってくださったと記憶していて、
それめちゃくちゃいいコメントだったなと僕思うんですよね。
けいすけさんのコメントで、
ブッククラブの空気感もいい方向にガラッと変わったというか、
結構ディマンニングだと思うんですよね。
会社じゃないところでみんな読んで、
事前にノートも書いてみたいなところなんですけど、
分からないことがあって、
それって初めて自分の学びになるみたいな観点になるので、
そこをけいすけさんがコメントしてくださったのが、
すごい良かったなと思いますね。
分からないことで言うと今回、
いまだにこの4章分かってない観点とかあったりしますか。
いや、今は分かった気になってます。
僕も同じ、分かった気になった。
多分数ヶ月後にまた分かんないってのがあるかもしれないけど。
なかなか毎章学びが多い。
また今回も良い本選べたなと思うんですけれども。
最後に何かけいすけさんのほうから、
これだけは言っておきたいっていうことはあったりしますか。
ブッククラブ関連でもいいですし、
何か宣伝したいことがもしあればでもいいですし、
今回の第4章のまとめという形でもいいですし、
最後にけいすけさんから一言コメントいただいてもよろしいでしょうか。
そうですね。
この前回のブッククラブの本、データコアプリケーションですよね。
その本もすごくいい本で、僕もリスナーとして聞く前から知っていて、
何かいい本だなって思っていて、
今回もソフトウェアのトレードオフとかを考えるっていう本だと思うんですけれど、
割と抽象的な話が多くなるなと思っていて、
ブッククラブの具体的なトピックに絞る話
今後のブッククラブでは何か先ほどちょっと出ましたけど、
何か具体的なトピックに絞って話してみるのも面白いかなと思ったので、
検討いただければ嬉しいです。
確かに確かに。
今回の例だとそれこそセキュリティモデルを考えるということで、
WazoomとかEBPFの深掘りしてもいいですし、
結構いろんな人がこのフレームワークとかこういったツールがありますよっていうのを
ブックを張ってくれてるので、
それに詳しい人を呼んで深掘りするっていうのも確か面白いですよね。
それであと一つ、やるやる詐欺をしているのが
トモヒサさんがフレームワーク、石板というフレームワークを公開してくださったので、
そこを作る過程というのを深掘りしながら、
このSmartの本の内容を絡めつつ深掘り会話をするっていうのもやりたいなと思っているので、
じゃあ貴重なフィードバックありがとうございます。
これを活かしてブッククラブのほうも収録のほうもクオリティを上げていきたいなと思います。
ありがとうございました。
ありがとうございます。
ということで本日はけいすけさんをお呼びして、
Smart第4章バランシング・フレキシビリティ&コンプレキシティの感想会をやりました。
けいすけさんありがとうございました。
ありがとうございました。
