00:06
じゃあまた次行きますか。なんかでもAIっぽい話にならなそうなのにするか。ここら辺があるかな。大体すべてがAIの話になってしまう。
すべてがAIになる。
未来へのメッセージっていうのが結構好きだったんですよね。
56ですね。で、112ページ。
これまた保守性みたいな話にどうせなっちゃうんですけど。プログラマーが知るべき97こと、新しいことを学びましょうと保守性大事だよしかないので、仕方ない。立つしかないんだから。
実は97個もいらなかったんですよ。
これ読み直してて、今回読んでおって思ったんですけど、リンダライジングさんですね。フェアレスチェンジの人です。
この人、こんなにプログラミングっぽい畑の人だったんだっていう驚きも、ちょっとごめんなさい。正直あったんですけど。
ここの中で紹介されているのが、学生のクラス持ってて提出された課題を見て、学生本人はすごいコードが書けましたって自信を持ってるんですけど、このリンダライジングさんが、あなた弟いるでしょ。弟さん賢いですよね。弟さん読めそうですか?このコードって言って。
いや、たぶんこんなにすごいプログラムは弟じゃ無理だねって学生さん答えるんですけど、それが仮に仕事だったらあなたの書いたコードがもう誰も使えないってことになっちゃうよって話をしてて、すごいですよね。
だとしたらあなたの書いたコードに一体何の意味があると思う?
火力高めのフィードバックしてるなと思ったけど、でも使えるコードってやっぱり動くコードであることは最低限大前提として、ちゃんとこの後も動き続けるコードである必要があるっていうのがあるなって思うと、この未来へのメッセージって表現がいいなって思いましたね、このエッセイのタイトルの。
うん、いいっすね。いや、ソースコードを弟に読めると思うって聞いて、学生だったら弟は別にコンピューターは勉強してないし読めないと思うよとか何を言ってるんだこの人って思っちゃうけど、仕事し始めると言ってることがわかるというか。
そうですよね、僕の考えた最強のアーキテクチャー残し上がってがありますからね。
そうとか、アーキテクチャーもそうだし、こうやったら解けるじゃんってすごい複雑なアルゴリズムをいっぱい書いて、結果後であの人が書いたやつよくわかんなくて遅いんだよねって。でも手が出せませんみたいな。
こういうケースではうまくいくかもしれないけど、配列のサイズがとてもとても長くなったらうまくいかないよねとかいうようなこととかも多分あるはずなんで。
あれ思い出しますね、PHPのコア開発してた佐吉さんが登壇で話してた、すごい最適化パフォーマーチューニングめっちゃ効くコードなんだけどあまりにも複雑すぎて、そのために書いたコメントがインライン、ソースコードに埋めてるコメントがすごい論文みたいなのが重なってるっていうような話をしてて。
03:16
いやーあれかっこいいですよね、なんかハッカーとしての俺が書いたかっこいいコードめちゃくちゃパフォーマース高いんだからこれマージせようじゃなくてちゃんと説明責任も取りつつやる。その結果面白いぐらいにコメントは長くなっちゃったけどどうなんですかねーってご本人がおっしゃってはいましたけど。
まあでもね、読めないお前が能力が低いっていうやり方じゃないっていうのめちゃくちゃいいですよね。
言葉強いですけどクソコードとか意味不明なコードに悩まされた人は優しくなれますよね。
うんうん、そう。難しいんですよね、やっぱりソースコードを書いてレビューしてる人たちの間にはやっぱり共通のコンテキストがあったりとか一緒に働いているとか一緒な経験をしてきたっていうものがあって、それはでもその瞬間ではやっぱりいろんな前提が共有されてるんだけど5年10年と動いていくともうその人たちはいなくなり、
そういう同じ経験というものは引き継がれないけどもソースコードだけは引き継がれていくっていう世界は世の中にはたくさんあって、その中でそれでもわかるコードっていうのはとても価値があるし、
わかんないコードっていうのはなんかそれは書いた人が悪いっていうこともあるかもしれないけども、どうしても時間を超えられない経験みたいなものっていうものがある中で頑張ってやっていくしかないんだみたいな、
というのはやっぱりしょうがないっちゃしょうがないなっていうのもありながら、そこのもどかしさみたいなものはありますね。
しかもね、言語自体が進化しているせいで当時ちゃんと当時の水準、機能としてはしっかり書かれているコードなのに、
経年劣化というか時代の方が進みすぎちゃったせいで、なんでこんなダセい書き方してるんだとか、出ちゃいますもんね。
ありますね。しかもそれはプログラマー同士だったら通じるんだけども、プログラマーじゃない人に対しては、だってプログラミングって劣化しないでしょ、物理的なものじゃないから、
風化とかしないでしょって言われるんだけど、いやでもそれやっぱり相対的には劣化するんだよねみたいな、最新っていうものが出てきたことによって、
今でレイテストってついてたものは古くなっていって、どんどん悪くなっていく、新しいものにうまく当てはまるようには作られてないんだよとか、
これがあるせいで動かなくなるんだよっていうことがあんまり通じなかったりするんで、そういうことでもやっぱり難しい、
面倒さぼってると簡単に言ってしまえばそうなんだけどっていうことでもあるんだけど。
でもね最近だと、いやだって10年前のスマホアプリ今見たらちょっとダサいなってなるでしょみたいな説明が伝わるんですけど、使えるんですけど、
あれなんですよね、ビーム系やってると、いやうちの使ってる管理画面、そもそも昔から今もダサいよってなってしまったりはするが。
06:07
とかね、i6、i11五感でモードで動いてますがって言われると、うーみたいなとかね。でもまだ使えるからさとかって言われると。
前の言ってるアクティブなそのXは何なんだってね。なんもアクティブじゃねえだろって。
そうなんですよね。だからちゃんと未来に向けて、当時はこういうアプローチでやったんだっていうものがちゃんと残ってるっていうのはやっぱ大事ですね。
ここら辺の話題ですごい関連して考えたというか、プロポーザル出してみたりもしたんですけど、
なんかその名前の付け方によって進化の方向性が変わる的なやつをいい感じに言語化してちょっと話してみたいなとか思ってるんですけど、
ただまるまるユーザーマネージャークラスとかつけると、将来これを見たエンジニアがどこまでどういうメソッドを生やすところまでどういう範囲とするかって予想がつかないじゃないですか。
こう使ってほしいっていうのが現れてないとか、明らかに誤解ミスリーディングになってるのってあんまり設計がいけてないというか、
すごい未来へのメッセージ性がないよね。お前のパッションが受け手に伝わらんぞ的なやつがあると思ってて。
わかる。
っていうのをサイバーネティクスとかの話を読んでてちょっと思いました。
すごいすごい最後に頂戴なストーリーが。
システム思考とかだと変化が遅れてくるじゃないですか。フィードバックが遅れてくるじゃないですか。
かつそのフィードバックをダスター側、機械側、ブラックボックス側がどういうふうに受信して、なんだっけ、ノーマンの人間の認知のモデルみたいな、
ヒューマン、人間受信設計のやつでもあったじゃないですか。受信してからいろんな7段階ぐらいフェーズを経てアウトプットなるみたいな。
そこら辺の話を考えてると、クラスの命名とかレイヤーの切り方とかによって、もうちょい本来は未来の人間の無責任な行動をもうちょいまともにできる余地がありそうって思っちゃいますよね。
わかるわかる。ぺけぺけサービスみたいな、作る時にクラットの機能全盛りのなんとかサービスを作ると多分みんな全部そこに集めちゃうから、
リードはリードでサービスに切り出しといて、書き込みと削除と分けておくと、消したいだけなのにリードのためにこういうクラスをDIしないといけないの?みたいな。
考えること増えてるんだよなみたいな。使ってないけどでもコンストラクターで必要とされてるので依存が増えてますみたいなことがあったりするとやっぱ辛いってなるんで、
なんかやっぱりユースケースを絞ってあげて設計するっていうのがいいのかなっていうのを、しかしそのユースケースっていうのは多分今後変わっていくので。
09:01
ユースケースが変わりましたっていうタイミングで、ちゃんとなんだ、俺も変わらなきゃいけないっていう感度が高いクラスを適切に作ってみてほしい。
最近でも思ってるのが、一つのクラスにどんどんいろんなものが入っていったら、でかいよねって思うからそこから分割しましょうっていうアプローチと、最初から切り刻んでリードもこういうリードとこういうリードと違うからユースケースが別々に分けましょうと。
分けた結果処理がまあでも結果的に一緒になったよねってなった時に人はちゃんとそれをマージしてくれるのかとか。
でかい方から小さい方に行くのか、小さい方をまあちゃんと必要な共通化をしてくれるためにマージしていくのかっていうのは、どっちの方が人は辿りやすいのだろうかってことはなんか思ったりとかして。
これはなんかまあでもそれを読んだ書き手によるよって言われたらまあそうだねって思えないんだけど、だからまあ共通的であるから共通化をした結果コンペキスとが違ったもので爆発する。
最終的に一番最後になんかデフォルトフォルスみたいなのがついてて分岐して、こいつがトレインの時はこうする、フォルスの時はこうするみたいにやられるといやそれってそもそもユースケースが違うから責務が違うんじゃないって言って本当に分割してくれるのか、間に合わせのコードを書かないかって思ったりして、なんかどっちがいいんだろうねっていうのはずっと悩んでますね。
まあなんか実は同じだよねっていうのはあれですからね、変更ここいじろうとしたら毎回ここいじってるなーってなったら同じだねってなるっていうふうに判断できるよなーって思ったけど、それはドライになってないからいつも変更ミスでエンバグするっていうことの裏返しでしかないなーって思っちゃったんですけど。
分けたいですけどね、重複したコードでもなんか違う進化の歴史をたどりそうだぞっていう時は分割したいからアクターで、いやなんかそれこそデータベースアクセスの話をしたいのにアクターまで意識するっていうのは変なんですけど、でもそのぐらいの気持ちでやりたいなーと思ってたとバッチ用のメソッドとウェブAPI用のユーザー向けのメソッドって安易に共通化したくないなーとか。
そうなんですよ。まさにそういうケースのことを念頭に置いてしゃべってましたね。
そこは別にレポジトリちゃんと作っとけば、本来的な意味でのレポジトリを綺麗に切れる人たちなら対処してそう。
そこがうまくできる人は多分分割しているものを、これ結局一つになっちゃったね、じゃあ一つにしていいよねってできるだろうし、でかかったねを分割できると思うんですけど、やっぱりプログラマーに人によって期待されているものが、例えばアーキテクチャレベルまでちゃんと考えて作れる人と、
12:00
ある種そういう人を全部のチームに配置することは難しいんで、ある種このチームにはとりあえずリリースしてもらうことが大事なんだって言ったときに、そこまで求めたいけども求めるのは得だよねみたいな。
でも今後それをメンテする人のことを考えたら、そこまでやっといてよって思うんだけども、動くものを出してくれって言われてる人にどれぐらい求めるべきなんですかねみたいなことだったり。
全員に同じ水準でってなると、いやじゃあ新人はちょっと大変だねとかなっちゃうし。
動くことを求める人には動くことまで求めればいいかなっていう気はしてて、それは何かっていうとすでに動いているものに対して悪意と及ぼさないことな気がするんですよね。
で、さっき言ったこれとこれって実は同じだよねって気づいたときにそれに気づけた人がまとめるっていうのはやればいいかなっていう気がしちゃうし、逆に言うとなんか元々混ざってたものが実は別々だったよねっていう拝見の方が難しい気がするので、
実は混ざってるよね、でもこれってAとBっていう概念として区別できるよねってそれはもうモデリングじゃないですか。そっちの方が明らかにハードル高いし、最悪と同じですよ、間違って混ざっちゃった悪い因子の方が影響がでかい。
僕はコード重複させてもいい側なんだよな、最近は。
いや、そう。
これは当時の個人的な流行りスタリがあると思うのでまた気分で言ってることがある。
自分も昔ドライだってこうやった結果、それでかなり痛い目を見たんで、ちゃんとコンテキストがこう違うんだなって思ったら分けて、分けた後にやっぱりでもこれコンテキスト別々だと思ってたけど一緒になったな。
そろそろ安定したかなって言ったら混ぜるがいいのかなと思いながら、でもその無駄な動きを結局せずに一発でかけるようになりたいなっていう気持ちもあるんですよね。
それはそうですよ。
それは失敗とか無駄な道は通りたくないですよ。
だからなんか、じゃあ重複してもいいじゃんって言って重複した結果、例えばその機能の担当を離れたりとかした時に、とか違うプロジェクトに移っちゃったり、いつまでも自分がそれを知っている状態にできるわけではないから、
どうやったらより良いものができるのかっていうことを常に考えながらコードを書くみたいなのをやってて、なかなか正解みたいなものはないと思うんですけど。
正解は最初から正解出すことですからね。
そうですね。
それは不可能なのでそれは不正解と言われてるんです。
一発でかけるようにどうにかなりたいなっていうのをずっと考えてますね。
なんかちょうど72章にシンプルさは捨てることによって得られるって書いてありますよ。
ああ、そうそうそう。でもそれは一個ありますよね。なんかその、このケース捨てるとすげー楽になるんだよねみたいなこともあるし。
15:05
ある種、なんか思ってるのが、ソフトウェアの複雑性みたいなものを、その複雑にしてるのは誰かって言った時に、プログラマーでももちろんあると思うんだけども、
そもそもそのもっと手前に仕様が複雑だったら、それはプログラムも複雑になるよねって思ってたりするんで、
なんかそのシンプルさを手に入れるためにユーザーに何かを諦めてもらう必要があるかもしれないとか、
なんかその、このエッセイでは宮川さんがそののを伝えるみたいな話があったけど、
なんかそういうことをどれぐらい考えていろいろ決断できるかみたいなことまで含め、行動書くってことが始まってるんだよなーみたいなことをちょっと思ったりもします。
仕様とか要求自体が複雑っていうのもでかいんですけども、なんか似たような話で曖昧とか定まりきってないみたいな話が上流肯定で発生した後、
そこを具体に落とした詳細な行動っていうのもなんかふわーっとするなーっていうのはありますよね。会話とかでも自信がないとこってゴニョゴニョなっちゃうじゃないですか。
言い切れてないとか、命名がちょっと広めなファジーになってるとか、でさっき言った曖昧な命名ファジーな概念ってやっぱり自分含めて未来のプログラマーに付け入る隙を作ってしまうので、
妙にメソッと入るなーとか、妙なところとカップリングしていくなーみたいな。やっぱり結合が、変な結合が増えると複雑度が上がるっていうのは前回も言ってたし。
そうなんです。
だからNOと言えること大事だし、結局本当にやりたいこと何ですかってやっぱり3回ぐらい聞き返すとか、これってあなたの頭の中にあるだけで何も説明されてませんよってちゃんと伝えるとか大事そうですね。
めちゃくちゃ大事ですね。
やだなー、人を疑いながら生きていく能力大事ですね、プログラマー。
そうですね、顧客のこともやっぱり疑わないと。
その話もありましたよね。
そうそう、あったよなーって今思いながら。顧客の言葉をそのまま受け取らないっていう。
すみません、やつで。
でもなんかそれ読んでて、顧客は別に目的が達成されたらなんでもいいよとか、最適化したいと別に思ってないよみたいな話もあったりとか。
エンジニアだとね、これ無駄だから削りましょうよとか、最適化したくなるんだけど。
分かる。
でも別に顧客はそこまでは求めてなくて目的が達成されたら手段は、普段やってるルーティンの中のものの方が馴染みがあるからいいんだよねとか。
あとね、やっぱり売り物を作ってるっていう風に考えると、やっぱり卵一手間混ぜる必要があるホットケーキミックスの方が売れたりするんだよね。
そうそうそうそう。顧客がね、仕事したと思えるってことも実は大事かもしれないっていうのは。ボタン押してAIがなんか提言してくれて、それをただ喋ってるだけだと、もしかしたらなんかあんまり仕事してる気にならないかなってなると、やっぱなんか俺のオリジナリティとか必要だよなって思うと、なんか間に作業が入ってた方が良かったりするかもしれないとかっていうのはありますよね。
18:23
そうですね。やっぱりAIにコード書かせて見てるだけだと退屈なんで、やっぱり紙に印刷して反抗をさないと。
そうなんですよね。
いやそうじゃないですよ。だいぶ騙されてる。
いやでもなんかその組織として求められることと、個人が納得してるとか、利害を感じてるってことはなんかあんまり一致しないっていうこともあるよなっていうのは思いますね。反抗を押した方がやってる感が出るみたいなこととか。
いらない仕事は削っていった方がいいと思うし、何のためにDXとかITかとかって言ってるかって言ったら、無駄を削るためにやってるので、方向性としては本当はそっち側に行くべきなんですけどねってのは素朴に思いますよね。
あんまり無駄なこと削っていくと、無駄なのは私でしたってなっちゃうかもしれない。
そうそう。困るんですよね。
なんか他に気になって、ここら辺も話したかったなーみたいなありますかな。どんくらい話したい?結構喋ってるのかも。
今まあ1時間まだいかないぐらいですかね。もうちょいで2時間って感じです。
もう1テーマぐらいかな。
じゃあちょっとこれいきたいな。バイナリーは常に1つっていうやつですね。
バイナリーなんで2なのに1つなの。
確かに。なんかバイナリー、コロスケナリーみたいな。そんなくだらないことが今ちょっと頭の中にも浮かんだんですけど。
ちょっとこの話、今となってはバイナリーは常に1つって当たり前だよねとか。
まあこれはバイナリーの話ではあるものの、あともうちょい多分現代風に言うと、例えばコンテナは1つ、環境ごとに用意するっていうよりは、どっかコンテナ1つのほうがいいよねとか。
いくつもメンテするのって大変だよねっていうもの。
まあもうちょっと言うと、もともとのエッセイはWindows用とかMac用だけどテストテスティングはこれ、なんとかこれみたいな。
ターゲットごとに違うもので、そのコードに分岐が入ったりとか。
そういうものをやっていくと大変なので、環境の情報もバージョン管理の対象にしましょうねとか。
環境変数で切り替えられるようにしましょうねみたいな話をしているエッセイで。
これは多分今となってはもうみんな当たり前に思っているし、共通の理解にどんどんなっているよなと思っていて。
これを推し進めたものとして、The Twelve Factor Upってやつが結構実はその背景にあったんじゃないかなみたいなことをちょっと読みながら思ってましたね。
21:01
The Twelve Factor Up同じぐらいの時代か。
2011年にこのThe Twelve Factor Upが公開されていて、エッセイ自体は2010年に出版されているんで、ちょっとエッセイの方が前だった。
さらに言うと多分2010年ぐらいってまだクラウドが出始めてて、これからクラウドに移っていくぞみたいな時代感。早いところはもうクラウドだったりするかもしれないけど。
そうですね。The Twelve Factor Upは割とクラウドでもないか。
ヘロクが出してるやつなんで、クラウドの人たちがこういうふうにやるといいウェブアプリケーションってものが作れるよっていうその十二過剰みたいなものを用意したっていう背景ですね。
なので時代によってこのエッセイっていうのはどんどん当たり前のものになっていったよねみたいな。
もちろんCPUのアーキテクチャレベルでちょっと違うものはしょうがないよねとか、ARMとIntelが違うよねとかそういうものはあるかもしれないけども、考え方みたいなものはどんどんどんどん推し進められたなっていうのもあるんで。
なんかやっぱこの本のエッセイを読む時に2010年ぐらいまでのエンジニアたちがどういう経験をしてきたかっていうことに思いを馳せながら、この15年ぐらいでじゃあ我々の環境はどう変わっていて、このエッセイってものが当たり前になったのか、いや古くなってるのかとか、そういうものを考えながら読むっていうことの大事さがあるよなっていうのを、このバイナリーは常に一つってやつを読みながらちょっと考えましたね。
バイナリーまで意識してないですもんね、あんまり我々。
そうですね。
Web系のふわふわ言語を使ってるんで、コンパイルは何か仮想マシンってやつがやってくれるみたいな。
そうですね、Goとか書いても、なんかもう大抵用意されてるからそのレールに乗っかればどうにもなるしなって思っちゃうからな。
いやでもそうだな、ビルド中にコードの一部を書き換え、ターゲット環境ごとに違うカスタムバイナリーを生成するっていう話の紹介から始まってるエッセイで、似たようなことはあるのかなどうかな。
なんとかさんのためにはこれをビルドして、なんとかさんなりにこれをビルドしてみたいな。
まあなんかそういうことは昔はもしかしたら必要だったのかもしれないけど。
確かに僕のローカル環境だけXでばっか入ってたりするから。
そういうのがだんだん集合集権的になっていくというか。
そうですね、クラウド前提だとそれこそ顧客、一社に対して一環境とは言わないまでも、ある程度サーバーが分かれてて、このサーバーはこういうお客さんのためにこうなってますみたいな話とかがあったりするのかな。
昔はスペックがいいんでこっちに振り分けしてみたいなとか。
24:05
そうですよね。バリエーション、それこそCPUとかプラットフォームとかっていうのも含めてですけど、バリエーションに対してどのレベルで対応しますか的な話もある気はしてて、バイナリーは常に一つで環境設定ファイルで書き換えようぜ的な話をこのエッセイしてたりはするわけですよね。
そうですね。
ただ、ビルド中にビルドスクリプトでソースコードを書き換えてっていうところまではいかないにせよ、フィーチャーフラグとかで実行パス切り替えるっていうのもある種、ユーザーに提供しているシナリオはいくつかのバリエーションに分かれてるっていう見方もできるわけじゃないですか。
だから、それでもビルド中にカスタムスクリプトでカスタムバイナリー作るよりかはビルドされた生成物自体は一緒なんでかなりいいですよっていう話っぽいですよね。
そうですね。製品版と開発版は別にしたくなるよなっていう気もしては、でも若干アプリとかはどうしても賞味所の問題があったりとかいうのはあったりするよなって思いながら、開発版だけには実はこのデバッグ機能が入ってますみたいなとかね。
まあでもそれが多分、今だともうソフトウェアのレベルでやってしまうというか、いうことは多分大いにあるんだろうな、さっきのフィーチャーフラグみたいな話しかり。
ビルド1つって言ってもね、CPUの都合はやっぱどうしても避けられないんで、AWSのグラビトンで動かしたい場合はこっちとか。っていうのは一部はどうしてもない部分あるよなーっていうのは思ったりはします。
それこそあれですもんね、ローカルではM1使ってるけど、今晩はIntelでいいんだっけとかっていう話は、最近聞かなくなったな。あんまり使えるようになったからな。だいぶありましたよね。
環境差異で困ることがあんまなかったっていうことなんですかね。ちょくちょくセグフォーしちゃうみたいなのはあったかもしれないけど、今は安定していれば困らないっていう風にはなってるんだけど。
微妙にね、精度とかね、オプションがMac版だとこう、とかみたいな話はたまにあったりしますけど。
このエッセイに限らず、この本全体的に言うて時が経ってるので、古びてるものとか、しかし古びないもの、やっぱりユニックスの話とかっていうのは古びなくて、
ファインドをバツバツして、その後は精度をして、相当してユニークして、もう一回大以上に並び替えてみたいな、もう何回書いたんだなって思うようなフォーマントとかの話もあって、その辺とかずっと変わってないな。
なんなら最近ターミナリーにいることが多いから、むしろAIが書いてくれるから、叩く回数増え始めたかもなって思ったりとかもしてたりとか。
27:08
自分では叩いてないけど。
でもそうですね、通常の話というか、このエッセイに関しても抽象化して今でも何か学べることありますかっていうと、どこら辺なんだろうな、最初のパラグラフの最後の方の量かな。
ほとんど同じだけれどわずかに違っているというバージョンがいくつも生まれることは確かですみたいなことが書いてあって、そういうことやってると不確定要素を必要以上に増やしミスする可能性をわざわざ高めてしまっていると言えるっていうのは、いろんなレベルで今でも全然ありそうだなっていうような気はしますね。
ありますね。結局なんか人間って柔軟さがあるから、なんかオペレーション頑張ればできちゃうとかになると、これが起きがちなんですよね。ちょっとすまんがこの時だけ越してくれみたいな話を始めて。
そうね。だっていちいちワーミングとかちょっと出たけど、でも動いてるから、わざわざ手順書変更チームにリクエストして承認もらってとかめんどくさいなーってなりますもんね。
でもそれが結局、トゥエルブ・ファクターアップじゃないけど、一つのやり方に、一つの方法に収束するのを妨げてしまう。つまり自動化がやりづらいとかいうふうになってて、
いやー人間って柔軟だけど柔軟な上からこそめんどくさいなって思ったりすることが日々ありますね。
トゥエルブ・ファクターアップでいうと、10番の開発本番位置とか、12番の管理プロセス、管理タスクを1回限りのプロセスとして実行するとかがそこら辺の話に直結しそう。
平行性とかも、たぶん同じやり方に塗ってるからスケールアウトできるようになってるはずで、あったりもするだろうし。
やっぱり関数型やらないと。
確かに参照等価性が多い。確かにこの本が出たくらいだと、適当性みたいな言葉がだんだん広まっていくっていうのがたぶんあったような気がするなと思いながら。
そうですよ、イミュータブルインフラストラクチャーだってなりますもんね。
そうそう、シェフとかアンシブルとか、それがちゃんと実行されたっていうか状態になってるよなっていうのをサーバースペックってやつでチェックするとか、ありましたね。
そうだよな、クラウド出てきてサーバーは大事にメンテして使うんじゃなくて、変更したいなら捨てて作り直すっていうのがやっとできる。
アップタイムって叩いて2年見たやつ触りたくないなって。
ほこりかぶってそう。
そういうのはやっぱり、この本とその後どうだったかっていうことを合わせていろいろ見ていくっていうのも楽しみ方の一つとしてありそうなっていう気はしてきたな。
30:04
そうですね。ていうかDHH書いてないのか。
確かに。
いてもよさそう。
そうですね。なんかちょっと最後に著者の話をしますか。なんか著者の一番見てて。
一番熱いですよね。
そう。結構ね、結構こういう人書いてたんだっていうのを今読み返してありますからね。
そう、今読み返すと本当にありますね。誰だっけ。さっき言ってたリンダライジングさんとかもそうだし。ニールフォードもいるんだとかね。
そうそうそう。ニールフォードいて、知ってるぞこの人はって思いながら。
あと日本人の著者で森田さんっていう人が書いてますけど、森田はじめさん。
このイラストのアイコンとそのツイッターのアイコンが一致してなかったんで、リビルドFMでゲストで出てた森田さんだってことにこれを読んで気づきました。
いやーすごいなリビルド。ニールフォードあれだ、ソフトウェアアーキテクチャのその第2番が出るらしい。
そうですね。3月に出るって書いてあったから、じゃあ初版はそろそろ出放すかみたいな気持ちになりながら。
え、比べないんですか。時代が変わったな。
オライリーになるんで。
確かにな。
ちょっと分厚いんですよね本が。
あのぐらい厚いといいですよね。学習したなっていう。
まあ読むのは大変ですけどね。
あと著者見てるとマイケルフェザーズとかいますね。
いますね。
レガシーコード改善ガイドの。API設計の黄金率のすげえいい話だったね。
スコットマイヤーズとかもいるし。
あ、そうそう。
あれマーティンファウラーいない?
いなかった気が。
そっか、じゃあソフトワークスニールフォードだけなのかな。
たぶんそうだったはず。実践アジャイルテストの著者とかもいたりしたなとか見ながら。
テストの話でプログラマーと強調しましょうとか。
シフトレフトっぽい感じのことも。
シフトレフトって言葉使ってないんだけど。
ただテストするだけじゃなくてもうちょっと前工程の方にみたいな話が出てきて。
アジャイルテストっぽいなと思ったらアジャイルテスティングの著者だったりして。
なるほどって。それはそうかって思ったりとか。
ダンノースっていう人がいるな。誰だっけこれ。知ってる気がするんだよな。
名前は見たことある。
ありますよね。ちょっと調べてみるか。
ドメインの用語使いみたいなことを書いてますね。この本で言うと。
いいですね。著者紹介の中でも言葉を正しく使うということを常に重要視しっていう話が書いてあって。
でもそうなんだよな。言葉を正しく使わないとその曖昧さみたいなものだったり複雑さみたいなものにつながっていくんで。
とてもとても辛い思いを後々するんですよね。
ちょっと最近あった面白い話があるんですけど、収録公開できないので後で話します。
33:00
これはロッカーですみたいな。
ダンノースでくくったらプログラマーがセルビック27のことが出てきて循環参照してるの。
マジャイルとかリーンとかって書いてあったからそちらで見てるはずって感じですね。
20 years of BDDとかっていう登壇をしてるらしい。面白そう。
確かに。ビヘイビーアクト開発って書いてある。
あとはちょっと著者全般見てるとあれですよね。JavaとかCの経験がありますとか20年30年の経験、エンジニア経験がありますみたいな人がすごく多いから。
そうするとこの本が書かれた背景ぐらいから考えると90年ぐらいからプログラマーやってる人が多くてみたいな感じ。
やっぱりそれなりに年を重ねた人が多いなっていうのは読んでて感じましたね。
もしかしたら今だったらまた全然メンツは変わるだろうし、アップデート版というかその2026年にプログラマーがシルベック97のことみたいなことをやると著者陣は結構また変わるんだろうなと思って。
令和最新版ってやつですね。
そうそう。さっき最新版っていうのは良くないって話をした気がするんだけど。
相対的に古くなっていくみたいな。
それはそれで今日ちょっと読んでみたいなとか、じゃあ日本人だと今誰が書き手になるんだろうねとかっていうのも気になったりもするし、面白そうだなって思うけど、みんなブログとかノートに書くんだろうなって気がするんで。
あとあれでしたね、編集者で言うと前回頼んだ人はもう一回頼むべきなのか、いやでも頼むと頼まないの差群が出たらなんか嫌な感じなのだろうかみたいな。
プログラマーが知るべき194のことにするかみたいな。
倍にして。
倍にして。
でももちろんですけど、あんまり知らなかったというかお名前だけ聞いてもピンとこないなっていう方はたくさんいますもんね。
そうですね。やっぱり見てる範囲が違えばしょうがないという感じはありますね。
これなぁ、日本人だと誰なんでしょうね。まあでもそういう話をすると角が立つか。
まあそれはアウトテイクというか収録の外で。
いやー、ティーバラさん書いてほしいですけどね。
そうですね。
自分って。
自分。
今回も書いてますからね。
一個不具合にテストを書いて立ち向かうっていう、まさにTDDの話書かれてたんで、今書くとしたら何を書くだろうかっていうのはちょっと楽しみだなって思いますね。
いやでもそんなとこですかね、全体的に。なんか他にもいくつも面白い話はありつつですけども。
そうですね、なんか結局多分4つ5つぐらい、97分の。
なんか横断して触れたやつもあるから、まあ言うて10個ぐらいは多分喋ったと思うけど。
36:02
すごい、あと10回できるじゃん。
いやでも本当多分チームとか、若者がいるチームとかで一緒に一周に何個か取り上げながら、自分たちの環境と照らし合わせてこういうことできてるかなとか、こういう考え方あるんだなとかいうふうに読んでいくにはなんかものすごくいい本だなって思いましたね。
古くなってる部分もあるかもしれないけども、古くなってる過去の話を受け継いでいくというか、そういう過去が、こういう経緯が昔はあってね、みたいな。
今となって当たり前になってるんだけど当時はそうじゃなかったんだよっていうような話とかも含めて話していくっていうのはなんかいいなーっていうのは思ったりしましたね。
あれですかね、今週のお言葉みたいな感じで1エッセイずつ掲示板に貼り付けて、ありがたがるという。
ありがたい話ですっていう。
あれかな、そもそも書かれたのが15年前ぐらい、というか絶対年数というか具体的に何年経ったかっていうよりかは時代的にもうねソーシャルメディアもスマホも全然今と同じようにあって、クラウドもなくはないぐらいの時代に書かれてるので、そんなにめっちゃガラッとは変わってないんですよね。
多分ここから数年ぐらい経つとそのAI以前AI以降の差分がはっきりしてくるかなという気はするんですけど、それもあって今でも全然通用するなーっていう話が思ってた以上に多めでしたし、というかあれなんだよな、半世紀前ぐらいの本を読んでるからそれに比べると今っぽい話になっちゃうなっていうのはあるのと。
あとハードスキルよりとか具体のプロセスの話っていうよりかは結構マインドソフトスキルによった話が、こういう心持ち大事にしてこうぜが多かったので、それもあってあんまり古びてないなーっていう気が結構しましたね。
関数型プログラミングを学ぶことの重要性はなんかいい加減その当たり前だよって言われる時代がどっかで来てもおかしくないはずなんだけどな。
そうですね。いつなったらオブジェクト思考も学んでみるといいよっていう状態になるんだろうなとかいうのはちょっと楽しみというか、今後そうなったら面白いのになっていうのをちょっと思ったりしましたね。
そうですね。銀の弾丸の可能性がある候補として挙げられてたオブジェクト思考がどうなっていくかと。
まあでもそんなとこですかね。
そうですね。
いやでもこれでよく引用される本を一冊丸っと読めたんで。
97のことシリーズなんかあれですよねソフトウェアアーキテクトが知るべき97のこととかもあれ読んでなかった気するんだよな。
読みないなとかも。
刺さってるんですけどね。そんなに刺さってるんですけどちょっとまだ読んでないんで読まなきゃなと思います。
39:03
アーキテクト刺さってるかな。SREとスクラムマスターとあとなんかもう一個ぐらい刺さってるんですけど。
なんかウェブで読めるのはゲームクリエイターが知るべき97のことと、ゲームクリエイターが知るべき97のこと2と、あとアーキテクチャー。
もう97個じゃないじゃん。
もうすでにいっぱいになってるっていう面白い話と、ソフトウェアアーキテクチャーが知るべき97のこともウェブで読めて、プロジェクトマネージャーが知るべき97のことも一応ウェブで読めるように。
この辺のは全部日本語で読める本ですね。
僕あとあれか、エンジニアリングマネージャーも持ってるのか。これ読んだ気するな。
翻訳はされてないんですよね、確かそれは。
翻訳されてないですね。スクラム実践者が日本語で持ってて、SREとEMが英語で買ってるんですけど。
でもこれ短いエッセイなんで結構要所というか英語の本あんまり積極的に読んでなかったんだよなとかっていう立場からでも手に取りやすいんじゃないかな。
もちろん全部読まなくても十分に価値がある本っていうのもあるし、なんか著者の名前見てこの人だからだいたいこういうこと言ってそうだなっていうコンテキスト込みだと読みやすくなったりもするので、楽しみ方もできそう。
英語の勉強に、だから英語学習チーム読書会できるじゃないですか。
確かに。
乗務時間にやるかどうかはあれですけど、てなことを思いましたね。
いいですね。オライリーのサブスクリーンEMのやつあった気がするから、あれでチームで読めると一番いいのではっていう気がしてきたな。
翻訳できちゃうし。
そうそうそう困ったよ、翻訳できるから。
むしろオライリー全部ないのかな。
前調べた時にはこれプログラマーが知るべきはなかったはず、確か。
あーなんでだ。
どちらとだけ何があるか見てみるか。
97THINGSで調べて出てきたのが、エンジニアリングマネージャー、Javaプログラマー、スクラブプラクティショナー、データエンジニア、英語版はプログラマーありますね。
英語版はあるのか。
ソフトウェアアーキテクト、SRE、エブリプロフェッショナルシュルノーってこれどういう日本語になるんだろう。
強いな。
UXプラクティショナー、プロジェクトマネージャー、アプリケーションセキュリティープロフェッショナル、インフォメーションセキュリティープロフェッショナル、クラウドエンジニア、データエンジニア。
そんなにある人ある?
97THINGS ABOUT ASICS EVERYWHERE IN DATA SCIENTISTSHOULD KNOW。データサイエンティストが知るべき97の倫理。
倫理。
もうあるんだ。
データを扱う上でちゃんと。
大事ですからな。
大事だから。
倫理とか哲学ってなんか唯一の真実に目を向けるからシンプルになってくんじゃないのか97個もあんのかって思っちゃってる。
42:05
確かに。
100THINGS EVERY DESIGNER NEEDS TO KNOW ABOUT。
100MORE THINGS EVERY DESIGNER NEEDS TO KNOW ABOUT。
まあいっぱい勉強しましょうっていうことになってくる。
デザイナーさんはちょっと学ぶべきことが多めなのかな。
まあ書き手が集まりすぎちゃったっていう。
面白いな。
レベル別なのかな。
まあいいか。
まあそんな感じだと思いますオライリー学習プラットフォームで触れられるやつ。
いっぱい読んで勉強しましょう。
必殺読むと97個知れるんで。
だいぶ内容被ってますよねちょいちょい。
いやもうだからやっぱり保守性が大事という話と言語をいっぱい学びましょうという。
抽象化するとね。
音になってしまう。
まあそんなとこですか。
はい。
じゃあおしまいにしますか。
はい。
じゃあ定型文をまた読み上げます。
今週も放送を聞きいただきありがとうございます。
ではまた次回さよなら。
さよなら。
