1. readline.fm
  2. EP176 BEST SOFTWARE WRITING ..
2026-03-20 41:10

EP176 BEST SOFTWARE WRITING PART2

spotify apple_podcasts

## とりあげた本

『BEST SOFTWARE WRITING』Joel Spolsky編 翔泳社 2008


## mixi2

https://mixi.social/communities/513e0bc9-582b-4962-a9c1-c5c076175e08/about


## ShowNote

https://gennei.notion.site/EP176-BEST-SOFTWARE-WRITING-PART2-328c645d491180afabc5faf8fadcaa94

感想

まだ感想はありません。最初の1件を書きましょう!

00:06
スピーカー 1
げんえいさんが見てる強い片付け、強いテストの話も、よかったらよかったんだよな。
スピーカー 2
そうなんですよ。なんか全体、やっぱ全部面白いんだけど、なんかどうコメントしようかなみたいなことをこう考えるのはちょっと毎回難しいなって思いながら、
まあいいかつって付箋を結構スキップしてること多いですね。
スピーカー 1
というか、個人的には前の2冊、ジョエルが1冊書いてた2つよりも、今回の方が読みやすいし面白かったなって思っちゃった。
スピーカー 2
でもそれはわかります。なんかこっちの方がより粒ぞろいだなって感じがして、なんかどれ取ってもそれなりにちゃんと面白いなっていうのがすごいありますね。
スピーカー 1
でもそうですよね、なんかジョエルトップ20に対して世界選抜のベスト4を集めてるからこっちの方がそれは強いよなっていう。
スピーカー 2
今年のオールスターですみたいな世界ですからね。
しまいにはポールグレーマーが出てきたりとかして、それは面白いでしょみたいな。
スピーカー 1
チラッとだけ今名前出しちゃったんで、強い片付け、強いテストは。
まあなんかカターリ、カターリ、カターノシティとあれだな。
動的片付けか静的片付けの言語でどっちがいいんだっけって話と、
でその型、コンパイラーレベルでやらなくても、なんかしっかりしたテスト、単体テストとは言ってないかな、テストって言ってたかな。
動的検査ができる、実行時の諸々の処理をしてくれるものがあれば、
無駄にエディター上の文字数を消費して人間の脳みそ疲れさせる型みたいなものを書かないでもいけるし、いいよねっていう話でしたね。
これもちょっと時代性感じるんだよな。
ちょうど動的にやる勢の方に倒れて、極めて強くそれが出てたのが、2000年から2010年ぐらいなのかなって思ったり。
スピーカー 2
LLっていう括り方で呼ばれたりとかしてたりとかした言語がこの後、レールズを筆頭に、PALもずっと使われてただろうしPHPもいろんなところで使われてただろうしみたいなのもありながら、
レールズとかによって動的な言語で大きいものを作るっていうのが全然できるじゃんっていうのがこの2004年の後にはやってくるので、
しかし現代の我々は型がないと辛いという話を結構しているので、テストがあればもちろん壊れてるってことに気づけるのはそうなんだけど、
03:00
スピーカー 2
結局頑張って人間がテストを書くのに限界があるのではっていう気持ちになり、型があった方が良くないっつって、型ついてると便利だなって。
型もユニオンとか、一つの型ではなくてジェネリクスだったりとかいろんな型を扱う方法があり、そういうものをいろいろ覚えると引き出しが増えていいぞっていうのが言われてるよなと思いながら。
スピーカー 1
ここらへんはもう一回言い戻しがあるんよなみたいな気がしてるけど、そうなんですよね、テストによって保証ができる、継続的インテグレーション前提な気はするんですけど、
例えばあるメソッドとその中のコードを読んで、事前条件が本当に満たされてるんだろうか、それとも防御的にやる必要があるんだろうかっていうのを、引数の型とかがついていれば考えなくていいじゃないですか。
ここにはなんか、ウルトラスーパーユーザークラスのデータしか来ないですねっていうのが、ウルトラスーパーユーザー型が宣言されてるのがわかるんですけど、
テストでそこにどういう方が来た時にどういう行動をされるかっていうのがちゃんとはっきりしてるよって言われると、今からこのメソッドの中をどうにかしようって思って、そこのコードを開いたプログラマーが考えること増えるよなみたいな気がしちゃうんですよ。
スピーカー 2
2025年なんでしちゃうんですけど、26年とかしちゃうんですけど。
スピーカー 1
ただこのエッセイの中で言う、ノイズというか本質、ビジネスロジックじゃないっぽい型の宣言とかっていう記述、プログラミングとかコンパイラーのための情報、ノイズじゃん的な立場でこのエッセイ書かれてる気がして。
それはどういう気持ちなんだろうなーって思いつつのテストされていないものは壊れていると思えって71ページに見たことないぐらいでかいフォントで書かれてるのは、それははい、そうです、好きですって思った。
スピーカー 2
いや、ほんとそうって。
ほんとそうって思う。
テストされてても壊れてる可能性があるからな、みたいな気持ちがあったりしますけどね。
スピーカー 1
テストが壊れてる可能性とか、テストが壊れてないけど足りないが多すぎるますからね。テスト減らすために片付けてるんだよなーっていう気がして。
06:10
スピーカー 2
そうそうそう、十分なテストを書くとか必要十分なテストを書くっていうことが、それはそれでやっぱり一個の能力なので、やっぱその辺とか誰でもできるわけじゃないっていう、いきなり入って渡された人が全員ができるようなものではないから、やっぱ難しいですよね。
あとなんか、さすがにじゃあ全部をテストしますかっていうことはやっぱパーフェクトソフトウェアでもあったじゃないですか、結局全部をテストするってことはやっぱできないわけだから、ある前提があってその前提の中でこういうことはテストしなくていいでしょうというふうに省略した結果、その前提が知らないうちに壊れなくなっていて壊れちゃうみたいなこととかもあったりすると思うので、
もちろんそんな前提はない方がいいっていうのはあるとは思うんですけど、でも全部テストを書いていくっていうのはやっぱり難しいんで、なかなかテストがあっても壊れてないっていうことは難しいよなっていうのはあります。
スピーカー 1
でもそうですね、コンピューターが進化してくれれば全部のテストをやってくれる気がしてるし、とはいえあまりにも無限に近い組み合わせだと辛いから、最低限の気の利いた型宣言だけしてテストは全部機械がバーってやる、テストケースの作成から全部やるっていうのが、
未来じゃないかなとかたまに思ったり。
スピーカー 2
まあでも多分現実的な落とし置きはそこに行くしかないから、あとは人間はそのインプットとアウトプットを定義するっていうことを頑張りましょうねっていう感じになっていくんだろうなっていう。
それを渡しとけばAIさんがあとは吉野にやってくれるぞ、でこれを取ったから受け入れられたんだ、よしオッケーだよって言って帰ってくるはず。
スピーカー 1
いややっぱCPUとメモリが一番ケーラルキーの上にあるというか、低レアなのに一番大事みたいな。
スピーカー 2
まあ前提条件みたいなもんですからね。どこで動いてるんだと思ってんだいっていう話だから。
確かにダックタイピングみたいなものとかが便利だなっていうことはシチュエーションもあるだろうし、結局ダックタイピング的なことをしたいから小さいインターフェースを切ってそいつをガチャンとくっつけて動かすみたいなこととかっていうのは現実的にやってるなとか思ったりするんで。
便利な、だからどれくらいの規模とかどれくらいメンテするかとかによってその辺とかは多分力の入れ方を変えるのがいいんだろうなっていう気もします。
09:04
スピーカー 1
ああそうですね。まあそうだよなそうだよな。
スピーカー 2
半年ぐらいで捨てるものだったら、もしかしたらもうメンテしないかもしれないしとかでどうにか逃げ切れるかもしれないから、そんなに厳密にやらんでも、じゃあこのオブジェクトに全部突っ込んで渡したいとかってやる可能性はあるなと思いながら。
半年って聞いてたはずなのにって言いながらそれを3年後に触ってるみたいな世界観はよくある話だなって気もしますけど。
スピーカー 1
いいな、このオブジェクトに全部入れちゃえば面白いですね。変数1個しか使えない縛りの言語を作りますか。
スピーカー 2
昔思ったのがJavaで引数にオブジェクトって書かれてて、これもう全てじゃんみたいなことがあったから、つまり無限の可能性がやってくるんだなっていう気持ちになったことがあったんで、それでオブジェクトがやってきますみたいなのをちょっと思ってるんですよね。
PHPだとSTDって書いてあるかアレイって書いてあるかどっちかなんですけど。
スピーカー 1
まあアレイだろうな。
スピーカー 2
時と倍と柔軟な選択肢を持って適切に動向を選びましょう。
スピーカー 1
でもまあそれこそね、ある程度辛くないように見栄えというかコード整えておいてはLLMがやってくれるんで。
スピーカー 2
確かに確かに。
スピーカー 1
LLMに抜本的に書き換えさせられると合ってるかどうかわかんないからテスト必要なんだよね。
スピーカー 2
そうなんですよ。であとAIが読めないコードはやっぱり読めないので、当たり前のこと言ってますけど、やっぱりAIさんが最低限読めるっていうのは結構必要なんだよなみたいな。
やっぱりそのアレイの中に何が入ってるかわかんない状態でAIさんに読ませると多分変な方向に進んでしまうってことは起きちゃうんで。
じゃあそうすると結局やっぱりテストがないとねみたいなことになり、果たしてそのテストは全部網羅されてるんだろうかって、このテストは信用していいのかなみたいな。
そんなアレイに何でもかんでも詰める人の行動を見たときにって思っちゃったりするんで。
おっとこれは危ないかもしれないぞみたいになり、その後苦しい思いをする可能性はあるんで、AIが読めるぐらいにはきれいにしておかないとダメっていうのはありそうですね。
まあ大丈夫ですよ、AIは進化するんで。たぶん人間よりAIの方が進化早いんで大丈夫ですよ。
12:05
スピーカー 2
あと多分AIの方が読み込みのスピードも早いし、探索範囲も広いはずなんで、AIはその指導にもっと進化していろいろやってくれることに賭けたいっていう気持ちはあります。
スピーカー 1
ただなんか最近僕が、全然余談ですけど、最近作ったPHPのファイルが6MBぐらいあったんですよね。読めんのかな一発で。
スピーカー 2
そうですね、全部がコンテキストに乗り切らないから、ヘッドで何行目から何行目まで読むみたいな可能性とかあるかもしれないですね。
スピーカー 1
ただそうすると変数宣言してるところが失われるかも。自分で生成、もちろん手書きじゃないので自動生成したファイルがクソでかくて、怖くてエディターで開けないんですよね。レスとかで見てるんですよね。
スピーカー 2
いやこれから自分のジョブセキュリティのためにAIが読めない行動科学時代が来るかもしれない。
スピーカー 1
やだな、AIに勝てる知能。
スピーカー 2
普通にAIと一緒に仕事をする世界線があるんだけどなみたいな。
スピーカー 1
しかもそれのメンテをお前がやれって言われるのは連獄に近くないですか、もはや。
ジョブセキュリティと引き換えに何かを失って言い過ぎる。
スピーカー 2
明らかに主従が逆転してるって感じがしますね。
スピーカー 1
アンチAI過激派としてそういう人生もあるかもしれないということで。
スピーカー 2
そうですね。
スピーカー 1
次行きますか。
スピーカー 2
次行きますか。
スピーカー 1
これでも二人ともコメントしてるのが…。
もうちょい何か挟むか。
EAの話怖かったですね。触れたくないですけど。
スピーカー 2
そうですね。EAの話ちょっとだけしますか。
スピーカー 1
なんでこんなんが選ばれたんだろうなって思いながら。
そうそうそう。なんかすごい不思議で。
スピーカー 2
EAっていうのはあれなんですよね。
スピーカー 1
エレクトロニックアーツですね。
スピーカー 2
なんでゲーム会社ですよね。
FIFAとか作ってる。
スピーカー 1
NBA2Kとかやってる。
スピーカー 2
そこの会社がとにかく人を働かせ、長時間労働させ、
とにかく仕事をしろってことをひたすらやってましたよっていう話が書かれていて。
なんでそんなブラックな仕事の話がこのエッセイに載ってるのか謎でしょうがないっていう感じですね。
スピーカー 1
本当にただブラックな話だったんですよね。
15:04
スピーカー 2
最後にそういうのは良くないから制度を変えてこんなふうに会社が変わったんですよって言うのかなと思ったら、いやそんなことはなかったなみたいな。
そうなんかスカット系の話だと思ったらムナクソ系でしたみたいな。
スピーカー 2
そうそうそう。オチューバーみたいな。
スピーカー 1
あなたが利益計算やコスト分析をしているとき、そのコストが生の人間の尊厳に支払われているんだってことがわかっているの?で終わってますね。
スピーカー 2
怖すぎる。
要はここから得る教訓としては社員を大事にしましょう。そしてトム・デ・マルコンのピープルウェアにいろんな話が書いてあるんでそれを参照してくれっていうようなことだったりとか。
あとやっぱり人が辞めていくってことは採用にコストがかかってるんで、余計なコスト、要は結局トータルで働かせすぎると余計にコストがかかってるってことにも気づこうねみたいな話がジョエルがちょっと書いてたりとかもして、そういうところを汲み取ってくれっていうことなのかなって思ったりはしましたね。
スピーカー 1
前書きというか紹介文、ジョエルのこのエッセイの紹介文のところを見てみると、向上的に危機モードにするというポリシーが全く非生産的だということだっていうようなことが書いてあって、それを伝えたかったんでしょうけど。
スピーカー 2
よく会社名出してこれを載っけるのオッケーしてくれたねっていう気がしましたね。
スピーカー 1
あとあれですよね、マスラレフェルというかハテナ匿名ダイヤリーに告発文ぐらいのひそうさというか刺激的な内容になってますね。
スピーカー 2
1日12時間、週6日朝9時から夜10時まで働くみたいな。それで終わんないとさらにみたいな感じになってて。
スピーカー 1
ライブジャーナルってそういうコミュニティですか?この記事の初出がライブジャーナルっていうサイトでしたよって書いてあって。
スピーカー 2
どんなサイトか全然わかんないな。一応ライブジャーナルで検索するとインターネットユーザーがブログ記事日記を掲載し保持できる仮想共同体の一種みたいなのが一応出てくるんで。
まさにもしかしたらこれはマスラの可能性があるな。
スピーカー 1
でもすごい一時期シックスアパートに買収されてたんですね。
へえ。
シックスアパート、でも2005年だからこれより前か。買収が起こるよりこの記事が出てきたのが前ですね。
18:13
スピーカー 2
これどうなんですかね、権利とか書いた著者に許可を得てるのだろうかとか。
スピーカー 1
得ててほしいな、お前まで削除するんかってなっちゃうから。
スピーカー 2
でも著者の名前は書いてあんだけど。
著者の名前というかEAスポーズみたいな、名前っていうよりかスクリーンネームとかIDっぽいなっていう気がしますね。
まあちゃんと許可を得て載っけていることを祈るしかないな。
スピーカー 1
ああでもすごいなんかこのIDで調べたらワイヤードとかに記事が載ってる記事というか紹介ボードというか、ジャーナリズムされてますね。
スピーカー 2
スポースっていうのは今どういう意味なんだろうなって思って調べたら配偶者虐待って出てきました。配偶者って意味か。配偶者って意味らしいです。
スピーカー 1
なるほどヒニックですね。
スピーカー 2
EAスポーツをスポーツに書き換えてヒニックを言いたかったということなんだ。
著者が虐待されているかのような。
そう。
スピーカー 1
オリジナルの記事がまだ全然普通に残ってる。
スピーカー 2
みなさん本読まなくても買わなくても読めますっていう。
スピーカー 1
まあ暗くなりすぎて。次行きますか。
あそこ順番逆でしたね。強い片付きVS強いテストの方が後だったな。
スピーカー 2
まあまあ。
スピーカー 1
じゃあ番号自指定。ポールグレームいきますか。
スピーカー 2
いきますか。タイトルがすごいハッカーとはっていう。キーノートみたいな。しかもそれを言って説得力がありそうな人っていうのはやっぱポールグレームっぽいなみたいな感じはあります。
スピーカー 1
このエントリーのURLが客中で載ってますけどすごいですね。ポールグレーム.コムすらGH.html。グレートハッカー.htmlの気にするけど。すごいな。ザって感じです。シグニチャー。
スピーカー 2
もともとは貴重講演が元だったみたいなんで本当に貴重講演だからキーノートだった。そういえば。
21:05
スピーカー 1
まあそうだろうな。どこら辺が良かったですか。なんか久しぶりじゃないですか。この類の記事を。記事エッセイ話にまじまじと触れるのなんか久しぶり感がある。
スピーカー 2
そうですね。この本の中ですごいハッカーってこういう感じだよっていうのは、精査性にばらつきがあるよとかいろんなトップ調みたいなものをいろいろ書いてるんですけど。
自分が読んでてすごいハッカーの特徴でいいなと思ったのが、やっぱり好奇心が大事っていう話をすごいしてて。すごいハッカーを養成するために何が大事なんだろうねっていうところで。
好奇心が一番大事だよっていう、いろんなことに興味を持っていくっていうのが大事なんだっていうことを書いてて。なんかこれすごい自分もそう思ってて、結構好奇心っていうものがなくなっていくとやばい状態になるなって思ってたりするんで。
毎月どれだけ本が読めてるのかが、本がどんどん読めなくなってたりとか、欲しい本が見つからなくなった時って一番危ないなって思ったりとかしてるんで。そういう意味でもこの辺とか結構共感したりとか。
あとGoogleも採用周りのやつで、どういう人を取るかって言った時に、ラーニングアニマルを取るみたいな話をしていて、要はすごい能動的にいろんな学習をする人を取るみたいな話をしてたから、やっぱり変化が早い業界だからっていうのもあるのかもしれないけど、みんな同じようなことを注目してるなっていうのはちょっと思ったりしましたね。
スピーカー 1
そうっすよね。ハックするっていうのが自分の中だとほぼほぼイコール好奇心から来る行動みたいなイメージがあって。これどうなってるんだろうとか、これをこうしたらどうなるんだろうとか、もっとこうできるかもみたいな。そういうのってやっぱ好奇心だなーっていう気がすると。
好奇心がなくなったらこの職場で言うと何ですかね、エラーログとかあるけど、ふーんで終わっちゃうみたいな。
これは本当にいつものエラーログ界っていうのを、やっぱり興味持てるか持てないかでだいぶ違いますもんね、結果が。自制心っていうのも必要なんですけど。
スピーカー 2
そうですね。好奇心は猫も殺すみたいな話があるから。そこだけに引っ張られていくとちょっと大変はあるんですけど。後は好奇心、興味が持てないようなものはやりませんわ。
24:09
スピーカー 2
それはそれでやっぱなかなか会社員を飼育上では大変だなっていうのはあるので、ある時にはちょっと退屈な作業もやらないといけない場合もあったりしますからね。
スピーカー 1
なんかちょうど昨日、最近人に勧められた漫画を昨日ちょうど読んでて、なんか概念泥棒ってやつなんですけどわかります?
言っとけばずっと叩きすんだよな。じゃあこれは後で読んでてもらいたいんですけど。
ここの中で自分の理想、ネタバレしますけど、理想を失った人間とか予知を失った人間っていうのが無気力化されてる姿がすごい描かれてるんですね。
ちょっとまた本当にネタバレをしたことに対する罪悪感が芽生えてきたんで、あとは読んでほしいんですけど。
だからそれもあって好奇心のあるなしって大事だし、なんだろうな、生存本能とか根幹的な欲求っていうのとはちょっとレイヤーが違うのかもしれないですけど
どう生きていくかっていうところにめちゃくちゃインパクトあるよなっていうのは、多分どんな人間とか生物でもそうなんじゃないかっていう気はするし、
その中でもプログラマーとかその中でもハッカーっていうスタイルでやってこうぜってなるとめちゃくちゃ大事?
ポールさんが言ってるんだから大事なんでしょうけど。
スピーカー 2
まあなんか一番いろんなことに好奇心持ってそうな人だからなっていう感じは。
スピーカー 1
で逆に言うとその好奇心で生きていきたい人にはすごい良い領域だなっていう気もなんかするなぁとか思ったり。
ね。
面白いということとか小さくいやらしい問題とか結構いいなーって。
そうだよ、やっぱり文才がないとダメだって言ってたしな。ジョエルが言ってたし。
スピーカー 2
見出しもすごい説のタイトルもわかりやすいし、読みやすいんだよな、みたいなことを思いながら。
スピーカー 1
読みやすいですね。天才かと思った。
スピーカー 2
だから結局読みやすくて引き込まれる文章を書けるから、二人ともここにコメントしちゃうよねみたいな気持ちになりながらノーションのメモを見てるんですけど。
27:08
スピーカー 1
そうっすね、金銭に振れる部分もありますもんね。
スピーカー 2
だからすごいハッカーになるために、ないしはすごいハッカーであり続けるためには、学習だったりいろんなものを面白がれるとか好奇心だったりとか。
やっていけるのかなって半分思いながら。別にすごいハッカーになる必要はないと思うんですけど、憧れるしなっていうのもあるから。
スピーカー 1
そこら辺でめちゃくちゃグッとくる文章が今日流れてきたんで後で貼っておきますね。
スピーカー 2
ありがとうございます。
スピーカー 1
なんかあと2,3桁バズってたら普通に名前出すんですけど、ちょっとまだセンシティブかもしれないんで。
いい文章だな。
あとあれですね、この本は全体的にパイソンなんてやめとけって言ったり、すごいハッカーはみんなパイソン使ってるみたいなこと言ったり。
パールは正規表現とかいろんなめちゃくちゃ便利だけど難解なツールを生み出した。それが不才になってみんな困ってるみたいなことに言及した次のエッセイで、パールは最高の発明だみたいなこと言ってたり。
スピーカー 1
いいですね、やっぱり個性の強い物書きというかエッセイストを集めていくとエッチが立ってていいなっていう気が。
スピーカー 2
いいですね。みんないろんな物に苦しめられ、その代わりにこれが最高なんだっていろいろ経験してたんだなっていうのは。
みんなPHPに苦しめられる時もあるし、パールに苦しめられる時もあるし、いろいろあるんだろうなと思いながら。誰かが置いてたVScriptに辛い思いをするとかいろいろあるんだろうなと思いながら。
スピーカー 1
PHPだけは言語としてはそんな褒められてなかったな。PHPなんて使ってる人は言語そのものには興味がないみたいな、いつもの描かれ方で。
PHPなんて使ってるようなやつらは、それよりもそのツール、ソフトウェアによってどういうコミュニティが出来上がっていくとか、そこをどうしたいかみたいな方に興味が向いてるみたいな。
スピーカー 2
いやー、歯ブラシだしなと思って。 そうすると今まさに歯ブラシなんだよね。
完全にそうだよなと思って。 うん。
いやーいいな、素敵な言語だ。 多様性があっていいな。
スピーカー 1
次のエッセイ行きますか。僕もコメント書いてあるんですけど、お前これ話したかったんだなみたいな雰囲気を自分のコメントが分量的にもかもしらしすぎてて、話したのが恥ずかしいので、次行きましょう。
30:22
スピーカー 2
はい。
スピーカー 1
生命でhttpリクエストね。ありましたね。でもこれタイトルが面白いでしょ、受賞の。スターバックスは2フェイズコミットを使わないじゃないですか、次。
スピーカー 2
そうですね。
スピーカー 1
これいいですよね。こういうの好きで。
スピーカー 2
ちなみに私この本の目次を見て、もうどっから読んでもいいやつなんだなって言ってパラパラ見て、とりあえずちょっとこのスターバックスは2フェイズコミットを使わないってどういうことなんだろう、これから読むかつってここから読みました。
スピーカー 1
面白かったですよね。スタバの注文から受け取りまでの非同期処理でみたいな話をずっとしてて。そんなに長いエッセイじゃないですけど。
スピーカー 2
途中で注文したらいいんだけど、ミルクが足りなくなってこれは払い戻しないといけない時はどうしたらいいんだとかいうこととかも実際にモデル化して考えるっていうのをやってたりとかして。スタバの本社の人とかは業務フローを書いていくことを考えてるかもしれないけど、現場でこんなときってそんなことは考えねえよなと。
ここで思いながら。
スピーカー 1
飲食店っていうか、ああいう状態で利益を最大化するにはスループットに着目してそこを叩いて改善する必要があるっていう話をしていて。そのためにレジで注文を受ける人と実際に商品を用意するっていうのを非同期化して処理してるみたいな話で。
その今、ぴーさんが言ってた例外処理に対して取り消しリトライ補償っていういくつかのデザインを使ってるよねみたいな話はしてますけど、茶内向けのマニュアルとかで多分こんなフローチャート使って説明するような仕方はしてないと思うんだよな。
33:16
スピーカー 2
フローチャートにはなってないだろうけど、ある程度でもやっぱ難しいですけど、ウォークスルーはやらないとこういう時どうするみたいな話は絶対出てくるから。
スピーカー 1
出てくるでしょうけど、メッセージングだとか非同期処理だとか、スフィズコミットだみたいな、ダイアグラムでフローチャートとかで示された方が難しくなりそうだなと思う。
スピーカー 2
そうね。
スピーカー 1
商品購入者ってアクターがいてみたいな話をして、まず最初に注文を受けた人が後ろの、スタバって自分でコーヒー入れないですもんね。
スピーカー 2
自分ではいれないですね。
ですよね。だから注文を受け取った人が注文を、コーヒー用意してくれる人に伝えたりとか名前が書いたカップを渡したりっていうところが、点線の矢印でつながってるわけですよね。ここは非同期ですって。
スピーカー 2
そうです。
でそのレジ注文を受けた人は、自分にリクエストを飛ばしてメッセージを送ってきたアクターが、実際に商品を受け取れるかっていうのは関心がないから、そこでいたその人とのプロセスは終了してみたいな。
スピーカー 2
あのランプの下で待ってくださいねって言って、アクターはランプの下に移動してずっとポーリング処理をするみたいな感じですね。
スピーカー 1
これさっきの現実世界の写像みたいな話とはまた別の香りがしますけど、難しいですね。簡単なことを難しく書かざるを得ないんだな、ソフトウェアっていう気がしちゃうな。
スピーカー 2
そうですね。だから厳密性みたいなものに近づいていくと、たぶんどんどん難しい。1%しか起きないようなことも考慮してやらないといけないですよってことが出てくると、たぶんどんどん厳密に書いていかないといけなくて、厳密に書いていくのを全部文章でやるのは無理なので、
図などを用いてやるしかなくて、じゃあどういう風に図を書くかっていった時に、プログラマーたちはフロー図を書いたりとかフローチャートを書いたり、ダイアグラムを書いたりとかっていうことを色々やってるわけですよね。
だからある意味では人間がそんなことをしなくても、とりあえずバイトに来た人に、とりあえずここでレジ打ってこれやってくださいとか、この時はこうしてみたいな指示出しでどうにか処理できてるというのは、ある意味ではすごいことじゃすごいことなのかもしれないなって思いました。
36:09
スピーカー 1
すごいですね。やっぱりモデルの違いというか、無意識に引き出せるオブザベーションとかリアクションの数と質の違いな気がしますよね。
いやだってそれこそお客さんから注文を受け付ける時には、まず耳から音声を認識しますみたいなところまで、多分本当は記述しなきゃいけないじゃないですか。そんなことをいちいち意識してるわけはないので。
スピーカー 2
すごい。しかもルールがどんどん変わっていくわけで、今スタバとかだとモバイルオーダーができるんで、事前に注文して着いたらそのまま取って帰るみたいな運用まで来てて、スタバのみならずコンビニの店員は覚えることが多いみたいな話もありますけど、
やっぱりああいうことを人間は意外とさばけてしまうっていうのはすごいなっていう。厳密に書いていくとよくこんなものを理解してるな人はっていう気になりますよね。
スピーカー 1
そうですね。でもプログラミングしてて、メモリのバンチとかまで管理しないっていうのと同じか。
スピーカー 2
そうですね。結局複雑さを分割して統治してやってるから、レジやってる時は他のこと考えないよなとかいうのはあるかもしれないですね。全体像を把握する必要がないとかっていうのはあるかもしれない。
スピーカー 1
あれでしたよ。おとといランチに行った中華料理屋さんはホールの人が次のお宅さん案内施設注文取るみたいなゲートをやってのけてて一人で。すごかったですよ。完璧な割り込み処理と。
頭のメモリの容量がでかいとこういうことができるんだなっていう気が。 すごいですよね。
スピーカー 2
目も取らなくていいの?みたいなことありますよね。注文してる時とかに隣のテーブル行ってこっちのテーブルの話聞いてそのまま帰ってってよく注文混ざらないなって思ったりするし。
スピーカー 1
すごいですよね。見えないところにパス出す選手とかのビジョンってこういうことなんだろうなと思って感動しました。
スピーカー 2
確かに。話がどんどん逸れていくのが似た話で。寿司屋、海底寿司とかに行くと直接こうなんとか一つなんとか一つなんとか一つとかって言って依頼するけど握る人全部それが急に詰まれて順番にさばいていって巻物だけは別スレットに逃してみたいなことをやってて。
39:06
スピーカー 2
あれなんでそんなことできるのって思いながら不思議だなっていつも思ってました。
スピーカー 1
あれすごいですよね。たぶん現代において聖徳太子に一番近い気がしますよね。
スピーカー 2
そうですね。手を動かしながら記憶を押し必要なものはフォワードして、それを今喋りながらこのスターバックスは2フェイスコミットを使わないっていうことを全く同じようなことをしてたんだなってことをちょっと思いましたね。
スピーカー 1
しかもすし握るだけで難しいじゃないですか。ただ絶対そこにはリソース割いてないですもんね。ほぼほぼバックグラウンド処理してるから。
スピーカー 2
そうそう。サブエージェントがやってる可能性ありますね。
スピーカー 1
すごいですよね。
スピーカー 2
面白いですね。現実世界のアーキテクチャ面白いですね。
スピーカー 1
面白かったなぁ。なんかあれだなぁ。実世界のアーキテクチャ。一昨年のPHPコンファレンス講座でデータ構造の話をしたんですけど、
そこで優先順位付きのリストとか普通の中だとかスタックだとかっていうのを、現実の街同列みたいなのになぞらえて話してて、
病院の受付システムは優先順位が付いてますよねみたいな話とか。でも一般コンビニとかは中ですよねみたいなやつとか話してて、
それに似た匂いを感じて面白かったですねこのショー。
スピーカー 2
こういう話すごい好きだから、もっとみんないろいろ書いてほしいです。
じゃあまた次行きますか。
41:10

コメント

スクロール