00:07
4章が異色性の優先順位みたいな 話があって、ここは定理が効率より
異色性っていう話と、もう一個が さっきのあれですね、数値データ
は好き、フラットファイルに保存 するっていうのが触れられてますね。
ちょっと定理5のほうがよく聞く し、身近にあるという気もするん
で、ちょっとこっちの話を先にして しまいたいなと自分は思ったん
ですけど、結局バイナリティのファイル だと特殊なフォーマットになっている
と、そもそもその中身がよくわからん っていうのもあるし、テキスト
になっていると処理がしやすいよね っていうようなところもあって、
これは確かに今でもすごいよく聞く なって思うし、世の中みんなCSVとか
好きだよねっていうのも、結局違う システムに移行するのがやりやすい
編集もしやすいし、他のシステム でも同じように扱えるっていう
のは、そういうことだよねっていう のはあるなって思いますね。
おだしょー そうっすね。ちょっと前にポッド
チャストで触れたかもしれないん ですけど、AI、エージェンティック
コーディングするためのちょっと 自分用便利ツールみたいなもの
を作ってて、それのデータの保存形式 を完全なプレンテキストというか
マークダウンにしたんですよ。マーク ダウンにして、MCPとか生やして
MCP経由でテキストファイル読み書き するみたいなふうな全体の流れ
作りにはなってるんですけど、ストレージ 用S2ライトとかその他のバイナリ
形式にしなかった利点はめちゃ くちゃあるなって思ったのは、基本
的にはMCP経由でツールが定義されている ものをAIに叩かせていろいろ
データ読み取ったり更新させたり するんですけど、いかんさに自分
が作ってるツールなので全然まだ そろってないAPIというかツール
とかもあってっていうときにプレンテキスト だから最悪AIエージェントが自分
で直でそっち読み書きできたり とか、それこそCPとかMVとかで変更
したり移動したり破棄したりも できるんで、テキストファイルって
世界共通言語ですばらしいなっていう 気持ちになりましたね
おだしょー まあそれは裏口から手を入れてる
感じがして、大丈夫なのかって MCP経由じゃない場合は大丈夫なのか
ってちょっと思ったりもしました けど
おだしょー そうで、ただ複雑にしすぎない
っていうのを同時にやってるので 最悪自分がターミナルからいじる
03:02
かっていうことができるぐらい 単純化をしてるんですよ、設計として
でそれもユニックス的というか すべてがファイルであるっていう
のとプレンテキストであるっていう のと、あとファイルであることと
絡みますけど、階層構造、ディレクトリ ツリーで証言してるから何でも
できるギリギリ人間が生でも触れる ぐらいの感じにはしてて、これが
やっぱりデータベースっぽいもの とか使ってたら大変だったなって
思って
おだしょー だからやっぱりテキストファイル
って便利だなっていうの本当思います よね、AIの時代になって
寄りそうなんじゃないっていう気 もしてて、XLとかも中身はZIPで固
めてXMLプラス画像とかなんで、回答 すれば読めるっちゃ読めるんですけど
AIが直で読むにはちょっと大変 だよねって思うとやっぱCSVになって
たほうがいいよねって思ったり もするし、あとちょっと関連して
このテキストと言っていいかどうか ちょっとわかんないですけど、ウェブ
の世界もソースが読めるわけじゃない ですか、HTMLとかCSSとかって、それ
がやっぱプロプライタリーとか 非公開なフォーマットだったり
とかなってたとしたら、オープン じゃなかったらこんなにみんな
がいろんなものを開発するとか ツールを作ったりとかウェブサイト
を公開していくとかいうことって 多分難しかったんじゃないかな
っていうのを思ったりとかして、 だから実質テキストファイルみたい
もんだよねと、.htmlはテキストファイル じゃんって思えばそうなんだけど
なので結局ウェブのものがこんな に広がったりとか、この本では
ウェブの話はまだないけども、構成 結局こんなにもウェブが広がった
のはテキストファイルでオープン なフォーマットになっていて、機械
的に処理ができるっていうのがす げえ大きかったんだろうなっていう
のをちょっと読みながら思いました ね
おだしょー テキストそうっすね、プレイ
テキストじゃないとしたら何が 使えるんだ、それがぱっと思い浮かば
ないぐらいにはプレイテキスト 最高信者になっちゃってるかな
こうっすね
おだしょー まあでもあれですよね、それこそ
JSONとかXMLとかっていうのは分かり やすくテキストですもんね
そうですね、結局CSVの限界 だったりとか、JSから扱いたいオブジェクト
扱いたいみたいなところとか、タグ に意味を込めていろんなデータ
構造を表現したいっていうところ でいろんなものが出てきている
っていうのはあれど、結局全部テキスト なんで、頑張ればどうにもできる
06:06
という感じはありますよね
おだしょー そうですね、あれが別にバイナリ
であってもよかったはず
そうっすね、それを読み書き できる専用のツールみたいなの
があって、そのツールを経由して のみ変更可能みたいになっていて
も、よかったはよかったんだろう けども、そういうものがなしに
オープナーテキストになっている ことによって、だいぶみんなが
好き勝手できるようになったっていう のはありますね
おだしょー って言って思ったけど、あれか
普通にAPI的な世界観でバイナリ 使っても別に、それをデコードする
のは人間じゃなくてプログラム なんだから、オーマット決まってる
か困らんのかって言ってて、メッセージ パックって昔使ってたけど、今
どうなってるんだろうって思っちゃ った
懐かしいな
おだしょー 懐かしいですね
おだしょー だから、その辺でいくと音楽とか
映像とかいうものはファイルフォーマット が決まっていて、それのデコード
はどうしますかっていうのが専用 のコーデックみたいなものがあったり
とかしたりとかいうのがあるわけ ですよね、でもほとんどはリード
なケースが多いのかな、決まってる けど、それを自由に改変するみたいな
こととか、そこから例えば音声を 1秒から10秒までを切り出すっていう
のをタミナリでパッとやるっていう のは、なかなか難しいっていうのは
あるかもしれないですね、それを いろんなもの組み合わせていく
のが難しいっていう感じなのかな
そうですよね、インターネット ブラウザーもそうですけど、メール
とかもテキストでやり取りされてる から、便利なメーラーとかがすごい
たくさんくりやすかったのかな っていう気もしますしね
おだしょー そうですね、そんな中で ここにもう一個定理があって、効率
より移植性の話がありますね、これは ハードウェアに最適化しすぎるん
じゃないよっていうのを、いっぱい 早くするってことに時間をかけ
すぎても、結局未来には早いマシン になってるわけだし、むしろその
未来移植できるほうに考えておく ほうがいいんじゃないかっていう
ような話があったりとかしてました ね
そうですよね、ハードウェア が進化する速さがどうせめちゃ
めちゃ速いんだから、非機能要件 として現時点でギリギリ許せる
かなぐらいの水準を達成できてる んだあれは、1年後には君が頑張ら
09:01
なくてもハードウェアがどうにか してくれるんだからめっちゃ使える
ようになるっしょみたいなことが 書いてあって、これは本当にそうだ
なって思うし、現代、今日よりも これが書かれた時代背景考えると
本当にそうだったんだろうなみたいな そうですね
CPUのクロック数が無限に、 原因って言うとさすがに怒られるんですけど
バイバイゲームで上がって生き続ける とか
こんな方は修言語で書く と移植性が低いからやめたほう
がいいぞってことをひたすら書いて たりとかして
これすごいですよね、これより さらに30年前の本だったらたぶん
修言語めちゃくちゃ人間に読みやす くて便利みたいなこと言ってた
気がするんで
面白いですよね、そのあたり が、みんなどういう観点でそれが
いいっていうのかが全然変わって くるっていうのが、その時代背景
によって変わるっていうのは面白い ですよね
これで移植性みたいな話 理由と何ですかね、OSが変わるとか
CPUが変わるみたいな話だと思う し、今で言うとね、なんかiOSアプリ
っていうのをAndroidでも出したい なとかっていうのは分かりやすく
移植性の話になってくるかなっていう 気もするんですけど、なんか結局
下のレイヤーもOSが提供してる APIに対して適合できるかみたいな
話がこの移植性に大きく関わって くるかなっていう気はしてて、Apple
のOSだとこういうAPI使ってやって たのがAndroidだとどれになるかな
とか逆になんか名前書き換える APIの名前を書き換えるだけでほとんど
そのまま同じ感じで動くようだったら ポタビリティ高いよねみたいな
話になるかもしれないですけど 移植性っていうと厳密に自分より
したプラットフォームとかミドルウェア とかが変わっても動きますか
みたいな、もちろんこの言葉自体 はそういう意味なんですけど、なんか
逆もあるなっていう気もしてて 自分が叩いてる外部サービスの
ウェブAPIみたいな話とか、自分が 繋いでいってるSDKだったりミドルウェア
データベースでもいいんですけど とかっていうなんかOSとかOSの上で
動いてるミドルウェアとかそれの アプリケーションの一番下側にある
フレームワークとかっていう移植性 っていうと自分より下の話では
あるはずなんですけど、なんか自分が 載せてる○○API○○サービス連携
みたいな移植性では全くないんですけど ここで言ってることって現代
12:03
だとむしろそっち側より上の話 にも関わることが多いなあ、で
その上でそっちの移植性は気に したいよなあって思って、移植性
じゃないんですけど
そうですね、結局今じゃあ 例えばログイン機能作りましょう
って言った時にGoogleログインとか XでログインしましょうとかFacebook
でとかっていろいろそこがどんどん 依存先が消えていったりとかAPI
のとかSDKの提供が終わって
マジでFacebookログイン 対応やめるサービス多いからな
めちゃくちゃ
でXのAPIもお金をどんどん 取るようになって自動投稿を終了
しますみたいな話があったりとか じゃあそのサービスとしてそれ
っていうのは結局Xに投稿してくれる ことによっていろんな宣伝効果
があるよねって意味だったんだろう けども結局それの依存先はどこ
に差し替えますかみたいな話とか をビジネスとしては考えないと
いけないしいろんなものに今 昔はこのUNIXの話でいえばCPUが依存
先だったんだけどもそこ以外の ものもいっぱい出てきたりしてる
わけで現代のサービスはそこは 結構考えること増えたよねっていう
のはマジでそうですねっていう のはありますね
それこそメールを送る ためにSendGridを使ってますって
いったらSendGridのAPIを直でアプリケーション の中から叩いちゃったほうがいいんです
けどそれは効率はいいんだけど 異色性に欠けるよねって話と同じ
構図になる気はしててだから腐敗 防止相というか依存弱点させて
自分たちの中で1個中小化させた ものを挟んで一応ここを腐敗防止
相とするみたいなふうにしてや っとくかとかあると思うんですよ
ね
おだしょー 最後PostFixで最悪自慢 面ですれば何かなるとかしと
いてやりたくないなとか思うけど ヤンヤン
そうですねだからあと 昨今で言えばベンダーロックイン
みたいなこともちょっと近いっちゃ 近いですよねそのAWSにロックイン
されててこれを移植したいと思 った時に一応Google Cloudに移行する
にはどうしたらいいかとかっていうこと もやっぱ似たような話な気もする
し逆にOS周りはみんなが気にした おかげで結局ある程度そこは中小化
されてあんまり気にしなくても いいよってなってLite Ones Run Anywhere
みたいなこともあったし我々の 身近にあるものでいえばどっか
みたいなものでコンテナ化して いろんな場所で動くよねみたいな
ことにしてくれたりとかっていう のもあるしマルチビルドみたいな
15:04
ものも当たり前になってきたから Windows用iOS用MacOS用とかっていう
のも一個のソースでビルド複数 作ってどっちにも動くよねみたいな
こともできるようになって移植 性みたいなところは結構いろんな
ものが変わってきたなっていう のはちょっと感じますね
うん それこそめちゃくちゃ すげえ分散ストレージ使ったリレーショナル
データベースだけどNewSQLくんは すごいポスグレかMySQLどっちか
喋ってくれるから特に意識する ことなく乗り換えられるなとか
あれも素晴らしい移植性だと思 うんですよね
そうやっぱり自分は結局 Webっていう仕組みっていうのは移植性
が高い 素晴らしいとかって思った りは 移植性というか そもそも
Webっていうシステムがあんまり コロコロ変わるもんじゃないから
いいなとかって思ってたんですけど でも その上の買ってるブラウザー
コロコロ変わったりとか あと 移植 性が高いと ブラウザーで見れれば
移植性が高いと思ってたんですけど フラッシュってやつは死んだから
なと思うと 実は移植性がそんなに あるようでないようでみたいな
ことはやっぱあるんだなっていうこと をこれを読みながら思い返して
ましたね
おだしょー でもそれこそフラッシュ ショックウェーブなりアクション
スクリプトなり もろもろそこら辺 はやっぱりバイナリーでやって
たからアスキーじゃなかったみたいな アスキーじゃないんですけど 特に
我々は日本語を県内に生きてるから アスキーではないんですけど
おだしょー そうね だからやっぱ 現代版移植性とは何なのかみたい
なのは 結構 みんなどう思ってる かって聞くの面白そうだな コロコロ
は
おだしょー そうですよね ウェブキット から出てないのに移植した後は
なんぞやみたいな話かもしれない し
おだしょー そうね だからみんな どこを自分のサービスがコアを
握られてるのかとか どこに依存 してるのかっていうところから
差し替え可能なのか いや 別に その競合がないから無理みたいな
話もまでありそうだし いいですね ここは結構面白いですね
おだしょー 大事だと思うんですよね 違う文脈で重要性を増してきてる
なみたいな
おだしょー そうね やっぱりもともと重要だった
ものはみんながいろんなもので 解決をしてくれたから ボトルネック
というか問題が別に移った感じ は若干あるな
おだしょー 確かに確かに 問題の場所は異動
したけど 形は 形 メタな構図は 変わってないみたいな気もする
18:04
おだしょー そう そう そう
おだしょー でも 次行きますか
おだしょー 行きますか 第5章が これこそテコの効果っていう章
で
おだしょー この章だけエクスクラメーション
マークついてて すごい元気がいいん ですよね
おだしょー 息が良さそう ここが定理6 ソフトウェアのテコ
を有効に活用するっていう話が あって あともう一個 シェリス
スクリプトを使うことでテコの 効果を移植性を高めるっていう
話がありましたね
おだしょー ここ この定理7が一番 読み替えが必要な気するんだよ
な
おだしょー そうですね ここで言ってる でもテコを有効
に活用するっていうのが そうですね あれなんですよね よりプログラマー
は良いコードを書く 偉大なプログラマー は良いコードを借りてくるっていう
のが69ページあったりとか 71ページ も独自技術昇降群を避けるとか
っていう話があって 既存にある ものを有効活用せよという話が
あったりとか 全てを自動化しましょう みたいなところで 自動でいろいろ
できるようにしていこうねっていう のが話が入ってますね
おだしょー なんか我々の現代の 感覚でいくと これは普通ではみたいな
気持ちになっちゃうんですけど
おだしょー これは普通 こここそ ちょっと変わってくるかもなっていう
のがあるとしたら 車輪の再発明 っぽいものでも簡単にブワーッ
となんかすげえやつが一瞬で書いて くれたりするので
おだしょー ちょっとだけ気に入らない ものを改造して作るっていうのは
現代だと 逆に自分で作ったほうがいい ちっちゃいものとかだったら
作ったほうがいいねっていうのは ありますね
おだしょー あとはあれですよね 多分PHP使ってる このエコシステム
にいる人たちは割と いや でも そんなこともないか 結構ライブラリー
とかフレームワークを使って そこからあんまりはみ出ないみたいな
あまり自分でツール作らないよね って話よ 前 別の言語の人と雑談
したことがあって そうかもね みたいな 結構GoとかPerlとかって
自分でちっちゃいツールよく作ってる 人が多かったりとかするイメージ
があるんですよね
おだしょー わかる そのイメージ はかなり共感する
おだしょー そうですね やっぱり 現代において当たり前の感覚になった
ものと プラスして AIがやってきた ことによって またちょっとだけ
変わり始めてるねっていうのは ありそうですね
おだしょー うん ありますけど これ 結構有効に活用するっていう
21:01
のが 何だ やらなくてもいい仕事 を避ける 要するに車輪の再発明
とかっていうのを避けたりとか なる べくデファクトスタンダード
とか標準に乗ることによって 再利用 性を高めたりとか いろんな
ナレッジを自分でも使えるように する 律してる形式値を自分でも
使えるようにするみたいな話だ と思うんですけど ソフトウェア
を作るときに 抵抗の効果を使いやすく するみたいなことを意識するっていう
のがUNIXという考え方としては 主張 したい話なのかなっていう気は
しつつの ちょっとの労力ででっかい 問題を解決するっていうのがレバレッジ
が効くみたいな これは話じゃない ですか 本当に解くべき問題に集中
できるようにツールとかソフトウェア 作っていくみたいなことが大事
なんだろうなっていう気がして いて ビジネス要求に応えなきゃ
いけないのに あれじゃないですか リンターとか作ってる場合じゃない
じゃないですか
そうですね ビジネスの 要求がリンターを作るじゃない
限りはリンター作ってる場合じゃない ですね
そうですね リンタービジネス デザインを成してる企業ではない
限りは リンターってめちゃくちゃ 再利用性が高いし いろんなところ
で汎用性が高いというか 喜ばれる ツールではあると思うんですけど
解くべき問題がそこじゃなかったら それはレバレッジが効いていない
テコの効果が生み出せてないな みたいな気がするし 逆にできあい
のライブラリとかフレームワーク サードパーティーのツールとか
使うことによって 自分たちのサービス っていうのを作り上げられるんだったら
それはすごいテコの効果だなっていう 気がするし そこら辺の解くべき
問題に集中せよ そのために何を すればいいかなっていう話を この
第5章を読んで思ったりしてました ね
そうですね 当時としては その感覚が当たり前じゃなかった
っていうことなんですよね 多分 これわざわざ書かれたっていうことは
これあれなんですよね われわれ ってもGitとかGitHubが出てきて
完全にそれ以前の世界を知らない ぐらいの感じじゃないですか 特に
OSSの文脈だと
パッケージマネージャーも いっぱいあるしね
いっぱいありますね
いっぱいある 本当に
そうだから そこら辺のコード の所有権とか 他のコードを使う
みたいな話が そこのイメージが あまり湧いてないのかもなっていう
気もするんですよね
そうですね だから自分より うまくやってるやつが 世の中に
どんだけいるのかとかは分かん ないですよね インターネットも
ねえし だからそうなってくる と 何かをやりたいと思っても ファイル
24:08
に何回文字が出てくるかっていうこと をカウントしたいと思ったとき
に じゃあファイルを開いて スクロール しながら手で自分で数えてみたい
なことをやっていくと めっちゃ 時間かかるよねと でも グリップ
とかWCとかを組み合わせてやると 一緒にして それができるよねって
いうことを知ってるか知らないか とか 他人が作ったものを伝えて
自分が使って デバレッジを効かせる ことができるかとか しかも何回
やっても同じ結果が返ってくる しとか ちょっと変わってももう
一回やり直しができるとかいう のが ちゃんと理解して それが
素晴らしいことなんだっていうこと を知ろうねっていうのがあった
りするから その感覚はもうあった からな コンピューター触ってた
ときにはもう既に こいつは便利 そうだなとか コマンドFで検索
ができるんだなとか 確かにそれを 知る直前はあれだったかもしれない
けど 知ってからは それはそうよな っていう気持ちにしかならなかった
からな
そうだよな そうするとGoogleとかいう すげえめっちゃページがヒット
する検索エンジン出たらしいぞ っていうのを 一応リアルタイム
で見てはいるんで ああいう世界が 変わる体験っていうのを見てました
けど ただ今となってはそれ以前 は全く想像できないだろうしな
で 多分 今 コンピューターに触れ 始めた人たちはAIがあるのが当たり
前になって Googleで検索するとか っていう感覚はもう分からねえ
っていう感じになってるだろう し
だからGoogleで検索しても結局AI が答えるしな
そうそう あれっていう
あとはそうですね シェルスクリプト を使うことでテコの効果と移植
性を高める これはどうですか
そうですね
でもシェルスクリプトに恐ろしい ほどのテコの効果があるっていうのは
分かると同時に このシェル芸で 書かれた大変なシェルスクリプトを
メンテするのがつらいっていう 気持ちが囲ったなっていうことを
思ったりとかを思い返しましたね
ここで語られてるシェルスクリプト 今どこに行ったんだいみたいな
話だと思うんですよね
そうですね
でもAIなんちゃらまでいっちゃうと それこそスキルとかになっちゃう
と思うんですけど
てかむしろAIにシェルを書いて もらうみたいなふうになって
むしろまた戻ってきた気配も若干 あるなって自分の中にはあったり
しますね
そうだよな スキルとかあれ別に メイクじゃんと思って
そうそう
27:02
名前付きで手順が固められてる だけだから
そうそうそう 毎回同じ結果が出て ほしいなって 決まりきったことで
今までコマンドの引数を覚える のがだるいなと思ってたのを
全部AIに書いてもらうっていう ふうになったりしたから そういう
便利さみたいなのはあったりとか しますね
移植性が高いや そうっちゃそう なんだけど でもバックのコマンド
とどっか入ったLinuxの中で このコマンドのオプションがある
なしみたいな話があって ちょっと だるいなみたいな グニューのコマンド
とそうじゃないやつ 互換性がねえ みたいなのがあって こっちだと
シレが動くんだけど こっちだと 動かねえみたいな問題が現代にも
あって ここに書いてあったことが 移植性が高いが本当なのかみたいな
話はちょっとあったりしますね
おだしょー まあそうだよな コンパイルがいらないとかっていう
話で移植性が高いっていうふう には書いてあるもん
まさもセルスクリプトをC言語 で書き直すという誘惑に負けない
みたいな
おだしょー だからあれですよね PHPが入ってない環境がないのであれば
全部PHPで書いちゃえばいいんじゃない みたいな話に近いっちゃ近いような
気もするし
まさもそうですね 仮想マシンが 全部通信してくれるっていう意味
でいうとRubyとかPythonとかPHPとか 便利ですよね
おだしょー そうですね 一時期 確かホームブリューのインストール
のコードとか確かRubyで書かれて いたはずだから Macに入ってるやろ
みたいな前提があって 別にわざわざ シェルで書かなくてもよかった
っちゃよかったみたいなことにな ってたし
おだしょー そうだよな だから あくまで移植性 要するにわざわざ
違う環境に移ったときに作り直 さなくていいととてもうれしい
よねっていう話と 今 ゲインさんが 言ってた みんなPHPローカルに入ってる
よねっていう前提が満たされるん であれば PHPを語言語で書き直す
という誘惑に負けないとかそういう 話ができてくるわけですね
まさもそうですね きっとPHPもローカル に入ってるバージョンが違って
動かないっていう話が出てきたり とかして そいつらにそういうの
とかはあるんだろうけど 言うて そんなトリッキーなこと書かなければ
みんな ちょっとしたコマドだったら ファイルゲットコンテンツとかで
いろんなとこからデータを取って きてとかってやると思うんで
おだしょー そうですね ファイルゲット コンテンツ 本当に便利ですからね
30:00
まさも本当に便利ですから 本当 何でも取れるんだから あれで
おだしょー あれは だから全てを ファイルリソースとしてみなす
っていう意味では非常にユニクス っぽいなって思うんですよね
まさも確かに
おだしょー あれだって標準入力 だって インターネットの向こう側
だって取ってこれるわけですから
まさもそうですね
おだしょー はい 全てはストリーム だっていう前提で
まさも便利だな
おだしょー 便利です
まさも便利だけど プロダクション コードでは使ってほしくないな
って思いますね はい まあ でも こんなとこなのかな
一色性 うん
おだしょー いや 結構面白いこと 言ってるなっていう気はしますけど
シルスクリプトっていうのを読み 返る必要はあるんですけど めちゃ
くちゃ大事なこと言ってるなっていう 気はする
まさもじゃあ 次に行きますか
おだしょー はい
まさも6章が対話的プログラムの 危険性っていう話で 定理8ですね
カドの対話的インターフェース を避けるっていうのが触れられて
ますね あと 定理9で全てのプログラム をフィルターにするっていうのも
一緒にやって 最初の定理のほう から話していきますか でも 確かに
こうやってて 普段 ターミナルで いろんなコマンド呼び出してて あん
対話的って本当にないよなっていう のは 多分 みんな思ったりするん
だろうなと思いながら その背景 にはここから来てるっていうこと
ですよね こういう考え方が
そうですね これはユーザーが人間 であるとは限らないっていうのが
というか ユーザーが人間である とは限らないと前提に置くべき
だっていう話が 定理8と定理9を 導いてるはずで 対話的だとプログラマ
チックに処理できない っていう か あれですもんね Dockerファイル
書くときにhyphen1忘れて あれ なんか ビルド終わらないなみたいな
そうそう 途中で止まるみたいな ありますね
入力間違ってたみたいな
だから 当たり前っちゃ当たり前 なんだけど
でも 人間が使う上では対話的な のは非常に便利じゃないですか
便利ですけど 放置できないですよ ね 不便ですよね
そうですね 放置したいときは不便 ただ 前提にあるエキスパートというか
詳しい人向けのものであるコンピューター はみたいな世界観だと 確かに一切の補助
33:01
いらないんですけど いちいちコマンド というオプションとかを覚えられない
じゃないですか っていうときは だから人間としてはちょっと対話
を望みますみたいな気持ちになる
Unixという考え方において 過度の対話的インターフェースを避けるっていうのは
めちゃくちゃ納得があるんですけど 日常レベルで果たしてそれだけで
十分嬉しいかなっていうのは ちょっと悩むなって感じ
そうですね オプションが覚えられないから 一生懸命Googleっていうのを
上に出てきたサイトをちょっとずつ読みながら オプションでこうやってみたいな
この-hと-sと-何とかを渡してみたいな なるほどみたいなのを 一生懸命覚えないといけなかったですからね
それこそクロードコードのスキルとか 作ってるときに 僕が作るときは
この指定は省略可能にして 指定されてなかった場合は ユーザーに必ず聞いてくださいみたいな
プロンプトを入れてあったりとか あとASKみたいなツールあるじゃないですか
あれを使ったりとかしてますね
確かに 確かに
AI投げるときも前提として パラメータを全部先に渡してしまいたいなっていう
気持ちがいつもあるから それがないときはもちろん聞いてねみたいな状態にしますけど
だいたい書いちゃうんだよなって思ってて その発想はどっから来てんだっけって思うと
結構コマンドラインで実行したいときに 環境変数で渡す場合もあるかもしれないし
オプションで渡す場合もあるかもしれないし みたいな感じで結構
実行したらあと放置して やっといてねって状態にしたいなっていう
自分の中の考え方みたいなのが あるなっていうのは思いますね
結構環境構築のイニシャライズの処理とかで その人によってちょっとだけ
例えば社員番号をもとに環境を作るみたいなのが 一部必要みたいなときあったりすると
入力を求められたりとかして だるいなって思って
そういうのを演舞ファイルに書こうね から取ってくるようにしてねとかってやっとくと
その演舞ファイルがあれば 2回目構築するときはもう聞かれなくて済むよねとか
いうふうにできるなって考えたりとかするなとか
だからやっぱり自分の中には結構これが 本当に聞かないでくれって気持ちはすごいあるなっていうのを
結構読んでて思いましたね
でもそっかあれですね 対話的インターフェースを避けるじゃなくて
あくまで過度の対話的インターフェースを避けるって書いてるんですもんね
36:00
そうそう だから多分最初に必要なものを聞いて あとはバーッと実行させるみたいなのが
いいんだろうなみたいなことを思ったりとか
あとこれ対話的インターフェースを避けるって書いてるけど
高速的ユーザーインターフェースっていうふうな表現も出てきてて
本質的にはこっちのことを良くないものと言ってるのかなっていう気もするんですよね
そうですね これがある種この高速的ユーザーインターフェースっていうのは
あるタイミングでもしかしたら業務フローの中では人になったりとかしてたりとかして
この人に聞いてくださいとかこの人に依頼をしてくださいとか調整してくださいみたいになってたりとかして
自動化が難しいなって思ったりすることがあるなっていうのをちょっと連想したりするな
この中の例で面白かったのがスケーラビリティにかけるみたいなところもあって
一個一個アカウントを作るのに全部聞かれると辛いねって言って
そうっすね100人分のレコードを作りたいのに一個一個手打ちして
それが一人分のセットアップに20分かかりますだったら
20分後に数字6桁をうちにまた席に付かなきゃいけないみたいな
そう
辛いですね
辛いですねなのでそれをそうしなくていいようにちゃんとしましょうねみたいな話が出てきたりとかして
そうなんだよな
高速的ユーザーインターフェースはソフトウェアのテコの効果を利用できないとか
って言ってるのはまさにそういうところですよね
結局解決できる問題とユーザーが実施しなきゃいけないコスト支払わなければいけない負担っていうのが変わってないと
ROIが悪いってなっちゃいますね
ただ一方で例えばアンブできない操作とかこれ本当にやっていいのみたいなのとかは
多分対話的にした方がいいよねとかきっとあるんだろうなとか
そうですね犯行を押してもらわないと承認ができないとかそういうことですよね
そうで大体人はそれを見ずにYって押してエンターって押していくんですけど
そうなんだよなセーブデータを上書きしますかって
はいって
あとAIにやっていいって聞かれたらもうなんかめんどいからはいってみんな押せるでしょって思ったりとかして
デンジャラススキップみたいなやつとか最近だとオートモードが出てきたからある程度
事前にやっていいよっていろいろ異常できるようになったりとかもしましたけど
39:02
その辺は結構トレードオフというかの関係にあるなっていうのはあったりしますね
そうですよね人間も同じですから権限を与えていいか悪いかっていうのは結構ちゃんと統制聞かせなきゃいけないところで
その後にあるが全てのプログラムをフィルターにするっていうので
でこの辺とかはあれですね多分皆さんやってるような
SDインSDアウト使用しながらSDエラーとかも使いながら結局フィルターでデータを運行していくみたいな話のところですね
それが結局対話的だとそれができないから辛いよねっていう部分もあったりとか
対話的にやらないためにじゃあエラー情報ってどうやって扱えたらいいんだっけとか
その出来上がったデータってどうやって渡していくんだっけみたいな話が書かれてるってところですね
いやもういっぱいやったな
面白いのはプログラムはデータを作らない人間が作るとか
コンピューターはデータを一つの形式から別の形式に変換するっていうことで
なるほどフィルターってそういう意味で言ってるのかみたいな気持ちになったりとか
こういうのを見てるとアレイマップとかアレイフィルターとかそういうのをちょっと連想するな
PHPの世界でいうとみたいなことをちょっと思ったりしましたね
配列があってこれをトランスフォームしていくというか
そしてだんだん関数型みたいな発想になっていくんだよなーみたいなことをちょっと思ったりとか
大丈夫ですパイプっていうかっこいいのが生えてくるって大丈夫です
PHPにもやってきましたからね
そこら辺でこの章の締めかなこれ最後のページかな
103ページ見ると全てのプログラムがフィルターであることを忘れずにいれば
高速的プログラムを開発してしまう危険を避けられる
プログラムから発生するデータの受け取り手が人間ではなく別のプログラムかもしれないことを念頭に置いておけば
アプリケーションをユーザーフレンドリーにしたいと誘惑に打ち勝つことができるって書いてあって
すごいですよねついにユーザーフレンドリーにしたいと誘惑に打ち勝つっていうことを言い始めて
おおすごいって思ったんですけど
そうなんですよねなんか作業をするエリアは人間よりコンピューターの方が圧倒的に効率というか生産性が高いので
そういう隅分けをしとかないとやっぱり人間が本来持つべきクリエイティビティみたいなところに
42:03
やっぱりアプリケーションユーザーフレンドリーにしたいっていう誘惑に打ち勝っていく必要があるなーっていう気持ちになりますよね
やっぱコンピューターが得意なことを人間が得意なことを隅分けをしないといけないからね本当
人間よりも単純な計算をコンピューターは連続してめちゃくちゃすごい勢いでやってくれるっていうことを
どれくらい感じているかどうかによってあれですよねコンピューターを上手に使えるかというか
自分が楽しくコンピューターに働かせられるかみたいなことはやっぱあるから
そこがユーザーフレンドリーじゃない方がいいんだっていうことがちょっと直感と反するかもしれないけどプログラマーじゃない人とかは
でもそういうところを発想転換できるとあれ実はこれ全部コンピューターにやらせたらいいのではみたいな
人間が頑張ってやってたけどこんなことやらなくてよかったのではみたいなことがいろいろ出てくるんだろうな
それを多分アシストしてくれてるのが今のAIでみんなこれが意外と便利になるみたいなことがいっぱい出てきてたりするんだろうなっていう気もします
すごいですよ今後ますます高速のアーキテクチャーが導入され人間の能力が見劣りするようになっても小さなプログラムは人間の能力に制約されることがない
それに前に述べた通りプログラムは不平を言わず生意気にもならず凝結もしないって書いてあって
生意気は最近言う気がするなという気がしてますか
向こうから喋ってくれたら当時は思ってなかったからな
だからソフトウェア設計者はアプリケーション小さなプログラムに分割し一つ一つにアプリケーションの一機能を受け持たせるってことが大事なんだよっていう
これはめちゃくちゃ今でもその通りな気がしますね
そうですね
でもやっぱりここら辺のことを思いながらアプリケーションを書いていくのはやっぱり楽しいと思うんですよね
楽しいと思う
これはビューティフルだぜみたいなワクワク感がある
人によってそして世界の認識が違ったりするからな
方向性が違うとこれがビューティフルだっていうのと俺の方がビューティフルだっていうのでぶつかると
とても大変だったりするんでなかなか平和になってほしいなと思うんですけど
筋が通っていればいいんですよ
これで基本的な
