00:07
きんじょうさんはどうでした?この一部で、ここいいなーって思ったとことか。
ちょっと戻っちゃうんですけど、第5章のリファクタリングの中で、どっちかっていうとげんえいさんがメモ残してくれてるところですけど、
コンピューターが理解できるコードは誰にでも書ける。優れたプログラマーは人間にとってわかりやすいコードを書くっていうのは、これはいいですよね。名言ですよね。
いいですね。元々はマーチンファウダーのリファクタリングの中に出てきた言葉でこういうのがあるんだよっていう紹介をしてるって感じですね。
マーチンファウダーはやっぱり言葉が上手なのですごいなと思った。
ちょうどこの話、これに近い話を前のポッドキャストでも喋ってたなって気がして、人間が読めたものがたまたまコンピューターで動くといいよねっていう話を、
なんかすごい最近したなーみたいなことを思ってて。でも理想はやっぱりこうですよね。人間にとってわかりやすくて、それがコンピューターでも動くっていう。
そうですね。あんまり人間はビットで喋りたくないよなーっていうのはやっぱりありますからね。
いや動くからいいでしょって言われて、せっかく構造化プログラミングされてるのに全部GoToに書き換えられると、ちょっとやっぱり人間読むの大変じゃないですか。
それはね大変だなーと思います。本当に。
何十行ってファイルが。
ちょうどこの本にも有害なコードみたいな話があって、なんかハームフルとかプログラミングとかなんかそういう論文書いてる人がいたなーって思ったら、名前がちょうど出てきたりとか。
そうですね。
実際コントロールが効かなくなりますからね。理解できなくなっていくと。
コントロールできないのはまだ相当悪い状況であるんですけど、まだ最悪ではないなと思ってて、なんか手を出さなくなるじゃないですか。
ハントッチャブルになっていくのがまずいんだろうなーと思ってて。
いやー、なんか言い方あれですけど、ウェブ系のプログラミング、一般的なサイズのウェブ系のプログラミングやってる人が、別にリラックスのカーネル読めなくても問題はそんなに日常的には起きないと思うんですけど。
うん。
って考えると別に読めないこと自体は問題にはならないじゃないですか。
確かに確かに。
本当はそこから目を逸らしちゃいけないのに、そこはアンタッチャブルだよねって言って避けるみたいな風になっちゃうと、いよいよまずいなーみたいな気はしてて。
そうですね。
心理的安全性が低いコードになってくるんで、対話をしなくなるじゃないですか。
03:00
そうですね。対話しなくなりますね。
それが良くないなーと思うんですよね。ありますからね。
そこはあれだからさーって言って、そっとコマンドダブルでファイルが閉じられていくみたいなことが起きますからね。
コマンドダブルか。今なんか頭の中でコロンダブルに変化されて、なんでこの人お前が共存しようとしてんだって。
全部消して。
対話する気がないという割にはアグレッシブだなーと思って。
閉じるって普段コマンドダブルでやってて、あれをキーボード何叩いてるんだっけなーって今すごい思い出しながらこの話喋ってて、閉じるって言えばよかったなーと思いながら。
そうですね。心の強いという話ですね。
そうですね。
あとあれだな、第5章はなんかひでえなって思ったのが。
ボブおじさんの本なんで基本的には3割本質、5割ぐらい冗談みたいな感じはしてるんですけど。
これ第5章の始まりが酷くて、マジでくだらない話なんですけど。
ロバート・シマーチェンがファウラーのリファクタリングを初めて読んだのは、息子のアイスホッケーの試合を見に行った時に応援席で見てたみたいな感じで。
えーと、原文まま読みますけど、本を読みながら氷の上の子供たちを応援する声が聞こえた。私も一緒になって応援した。私が応援したのはホッケーの試合ではない、本の内容を応援したのである。
こいつマジで何を言ってるんだと思って。
いやー、すごいおもろいですね。
子供たち応援してあげてと。
まああれですよね。子供の習い事について言ったらいいけど、別に興味ないし、待ってる間暇だなって。じゃあ本でも読むかみたいな、そういう感じですよね。
本の内容を応援していたっていうわけわかんなすぎてやばいと思う。
いやー、やっぱこう複雑なコードをシンプルに持っていくのに頑張れ頑張れと。
そうだ、いけいけ、メソッドのチェストだ!
いやー、いいですね、いいですね。
っていう印象に残った。
きのさん、ちゃんとこういうところを拾ってくるからな、いいんだよな。
肩でさえ話の長いポッドキャストなのに。
俺は割とスッとこう、あ、そうなのねって読み飛ばしちゃうんだよな、こういうところは。
06:02
なんか似たような話で言うと、イラスト、差し絵が全体的に、なんていうか面白いですからね、今回。
そうですね。
なんかずっと風刺画みたいなことをしてる。
このリファクタリングの絵もいいですよね。
なんかその穴に物をはめて並べ替えかなんかしてるとこなんですけど、はてなってついてても、何やってんだろうなあみごとになってて。
これ、誰の何を言いたいのかわかんない一瞬来るんだけど。
そうそうそう。
まあ、そんなところかな、第5章は。
あと6章が結構金城さんが熱量高くメモ書いてるって感じですね。
引用が長いのかな、6章は。
これ熱量、面白いなと思ってもちろんメモしてるんですけど。
第6章シンプルな設計のところですね。
で、これパッと読んで書かれてることの意味がよくわからんなあって思いながらちょっとメモしたのが一番下のところなんですけど。
そっちから行くと277ページ。
ヒンドル版の277ページはウィンドウのサイズ変えるとページ数変わるってことにさっき気づいたんで、頑張って探さなきゃいけないんですけど。
確かに、確かになんか絶対指定じゃなくて相対指定みたいな状態になってることですね。
そうですね、なんかページングと同じページなんで1ページに何件表示されてるかわからないうちの177ページ。
これと引用してるのが第6章の一番最後の説ですね、シンプルな設計っていうそのままのタイトルの説があって。
で、ここケントベックと設計の原則について議論した時に彼が言ってたのが、カバレッジ、表現力、単数化、縮小化の4つの原則を熱心に守れば他の設計原則ってついてくるよねっていうのことを言ってたよっていうのに紹介してて。
ちょっとあんまりピンとこなかったんですよね。
確かに確かに。
で、僕は現状を持ってるんでそっちを読もうかなと思った5秒後ぐらいに、あれオライリー学習プラットフォームあるなと思ってそっちから引っ張ってきたんですけど。
そうそう、なぜか元はあるんですよね。
そう、ハイパーリンクがね。
で、そっちを見てみると、ここのカバレッジ、表現力、単数化、縮小化の特にカバレッジが何言ってるんだっけっていうのがわからんなって思ったんですけど。
09:01
えっと、これか、the principle of design can be reduced to、設計の原則ってこれらに還元されていくよねって言ってて、カバレッジエクスプレッション、シングラリーゼーションアンドリダクションって書いてあって。
カバレッジって書いてあるやんけってなってわからんって思ったんで。
で、なんかいるチャットGPTとかオライリー学習プラットフォームのAIサーチとか調べてみると、ケントベックなんでっていうとあれですけど、XPのシロ本の初版かな、第2版でもあるのかな。
で、ここらへんのこと言ってるよっていうふうに書かれてたのが、なるほどこれは読んだことあるなわかるぞってなったんですけど。
カバレッジって言ってるのが、ちゃんとテストを書いて通しましょうみたいな。本当にカバレッジじゃんってなったんですけど、要するにテスト可能になってて、しかもそれが意図通りにパスしてる状態っていうのを保つべき。
っていうのがカバレッジですね。だからテストできないコードを書くな的なのはさっきのゲイさんが話してたのと繋がるじゃないですか。
テストが書きやすいコードになってくると、おのずと設計が良くなってくるみたいな。そこらへんの話でカバレッジって言ってますね。
たんすうかって言ってるのは、これは一つの仕事に対して一つの行動をしなさいみたいなやつなので、単純に言うとドライ的なやつですね。
同じ仕事をやるやつが複数のところにいるんじゃないみたいな話で単位使って言ってるはず。そうするとね、おのずと上昇度とか上がってくるじゃないですか。
ディスク消化も高度の最小化なので、不必要にモジュールとかクラス速さとかそういう話なので、なるべくミニマイズしましょうみたいな話だし、
エクスプレッション、証言力って言ってるのは、証言力この手前でも触れられててなかなかいいなと思ってるんですけど、
証言力なんだっけ、States Every Intention Important toProgrammersのところかな。だからプログラマーの意図を反映したコードを書きましょうよみたいなやつ。
っていうこの4つに綺麗に対応しているので、カバレッジ、証言力、単数化、縮小化が。これのことだよねっていう結論になって、すっきりっていう話でした。
そうですね、カバレッジとかは自分が想像してたのは、結局結論はさっきキーノさんが解説してくれた通りにはなるけど、やっぱり複雑な分岐があると、ここ本当はトーラインやろうとか、デッドコードだったりとか、
12:19
こういう条件って理論上もあるかもしれないけど、こっちに値がないときは絶対こっちも値がないんだよねみたいな、無理やりモックしたりとかすれば通るようにできるかもしれないけど、みたいな、そういう状態があると辛くなっていくから、全部パスする。
全部パスするようなものが欠ける。パッと見て、こういう分岐とこういう分岐があって、ここには入るよね、なるほどこういうときはこっちに入るんだよねみたいな、これで必要十分だっけみたいなことが、コード読んでパッとわかるっていうようなことなのかなっていうふうに、もうちょっと自分は読んでパスしたね。
なるほどなるほど。なんか僕これ最初読んだときにカバリッジっていうのがテストによるコードカバリッジの話かなっていうのは、結論当たってはいたんですけど、カバリッジを高めましょうって結構テスト頑張りましょうっぽい話にちょっと思っちゃって、
あれそれってなんか設計の、なんだその他の設計原則に、その他の設計原則がおのずとついてくるみたいな話と、なんかベクトル違う話してるんじゃないかなって思っちゃったんですよね。
確かにね。 まあでもなんかカバリッジが自然とカバリッジが満たされるようなコードっていうのを追求すべきだって考えると、ちょっとまあ納得感が得やすいかなとか思ったり。
そうですね。この6章の中でもカバリッジっていうその説があって、100%80%満足すると20%動くかどうかわからないコードが出来上がるよみたいな、本当にそれでいいの?みたいなことが問いかけがあって。
だから100%網羅されてる風にしましょうとまでは強くは言ってないけども、実際100%って到達不可能な目標だよねみたいな話はしてるけど、一応やれば上がるよねみたいな。
全勤的な目標として100%に近づけることはできるよねっていう話はしてるから、やっぱテストカバリッジとしてはテストカバリッジの話ですね。
その説というかその手前の説でいうとシンプルな設計の最初のルールのカバーされているという言葉を網羅されているという意味であるっていう表現は出てくるんですけど、ちょっとここも読んだ時にピンときてなかったので。
15:11
で、紛らわしいのが心持ちの話をしてる本ではあるじゃないですか。だから良いプログラマーとはテストもしっかり書くみたいなニュアンスで、ちょっとそういうバイアスというか視点でこの本を読んじゃってたんで。
だからシンプルな設計のっていう主語ではあるんですけど、なんかしっかりテストも書くんだぞ、わかったかっていうメッセージって思っちゃった話はありますね。読み方が雑だったという話ではある。
まあでもちょっとそうね、今改めてこの4つの話をされて、確かになんかむずいなこれだけ言って全然伝わらないような気持ちになりましたね。
なんかケントベックとこのボブジさんの中ではすごい議論した結果これだってなったのかもしれないけど、裏側にあることが確かにちょっとここのアケドム文章だとちょっと厳しいですね。
まあでもそれで言うと、なんかこの人が言ってるこういう話は多分あの本にあるだろうっていうあたりをつけて読めるのは良い時代ですね。
XP代本のファーストエディションとかマジで現物どうやって手に入れるのみたいな気がしてたんで、ちゃんとオライリー学習プラットフォームはファーストもセカンドエディションも両方別々になったんで、あ助かるって読んでました。
まああとはそうですねシンプリシティ大事だよっていう話で、時代ハードウェアとかソフトウェアの進化、ソフトウェアというかプログラミング言語かなの進化によって何が大事かっていうのは変わってきていて、
昔だったら拡張性とか長持ちするコードって意味してたのは、何でもかんでもフックを生やしてプラグイン的に色々とできる、増やす方向にいじれるみたいなやつだったのが、今はちっちゃくてシンプルなモジュールを組み立てましょうっていう風になってるよね。
っていうところ対比で拡張性っていうものがどういうことを本質的に意味しているのかが、昔と今だと変わってるねっていう話とかは、なるほど面白いなって思ったりしてましたね。
作ってるものの対象もどんどんどんどんバラバラになってるし、当たり前ですけどウェブのシステム作るのとスマートフォンのアプリ作るのは全然違うことじゃないですか、同じコード書いてるって言っても。
18:00
大分近いところで今例えだしてきたなと思いました。
けど、例えばそのネットワークがつながらない状態を考慮する必要があるとかって、ウェブのシステムの時はあんまりないよねみたいな。
いやもちろんその外出先、新幹線の中でノートバンクが開いてるとかはもちろんあったりはしますけど、とかもそうだし、じゃあね、スーパーファミコンのプログラムを書くっていうのとウェブのシステムはやっぱ全然違うしとか、
まあそもそも容量が足りない時代もあったしとか、今となっては、今でも容量みんな足りないとは言うものの、ストレージはまあ別にそんなに足りないなっていうことは言わなくなっただろうし。
ってなるとやっぱなんか、あとその継続的に変更してリリースしていく。例えばさっきの例でいけばファミコンのソフトとかって作り終わってリリースしたらもう変えられないので、継続的に変更していくってことを、
開発者はもちろん考えることはあるかもしれないけど、開発終わった後には考える必要はない。でもウェブのシステムやってると、毎日デプロイされていって、インテグレーションされていって、CICDが回っていってっていうことを考えると、ずっと保守していかないといけない。
っていうことはあるので、全然ちょっと考えること変わってくるよねとか、諦めをどこでつけるのかとかも、落とし所どうするかとかも全然話変わってくるよなってなると、じゃあ何を大事にしましょうかねっていうことをちゃんと考えておかないと、一口にシンプルな設計って言っても、どこがトレードオフになるんだっけとかってことはやっぱ考えないといけないですよね。
ここら辺はどうなんですかね、だからまた何か時代が変わったら別の話、別の設計原則っていうか出てくるんだろうなーっていうのは想像に固くないんですけど、
僕とかゲイさんだともう世代的にあれじゃないですか、ウェーブ2.0以降ぐらいじゃないですか、プログラミング始めたの。要するにインターネット当たり前でオフラインとオンラインは解き合って、コンテンツはネットワーク経由で配信されてくるみたいな、そういうネイティブ世代なので、
それ以前がわかんないですもんね、出荷したらもうそれで基本終わりですみたいな話はわからんから、わかんないですね、CD-ROMからインストールとかはしたことあるんですけどね。
ありますね、ありますし、そういえばCD-ROMに入って客先に持っていくみたいなやつを見たことありますね。
まじか、そこはないな。
最初は多分自分はウェーブじゃなかったからですね、働き始めた時は。
なるほど。
ウェブからコンテンツを取ってくるっていう機能はあったんですけど、ウェブサーバーの上にいるやつではなかった、厳密には店舗にあるマシンの上でIISが動いていてみたいな、あるにはあったけど、結局それは別にそこにインストールされているのとそんな変わらない仕組みといえば仕組みだったりしたので。
21:17
そうだよな、デプロイ方法は変わりましたもんね、なんかTapistranoとかで頑張って部分的に書き換えてたのが、もうインフラごと入れ替えればよくないみたいな、イミュータブルインフラストラクチャーになったおかげで非常に楽すぎるみたいな、あまりにも符号的解決すぎるみたいな。
そうなんですよね、コンテナの時代だな、コンテナの時代って本当すごいなって思いますもんね。
すごいですよね、環境構築ミスった環境ごと捨てればいいじゃないなんて、信じらんないですよね。
そんなにリソースバンバン使っていいんだみたいな、ちゃんと世代管理してシンボリックリンクをシュッと張り替えてみたいな、そういうのではないよな。
最近やっぱ近所さんのスパゲティコードのやつを見て、昔のGoToのコード見た時に。
あれは現代のGoToですよ、綺麗なGoToしか使ってない。
うんうんうんみたいな気持ちですけど。
またイールドとかと同じ世代のやつ。
ちょっとよくわかんないって感じになっちゃうんですけど、ちょっと私GoToにはそんなに詳しくないんで。
やっぱGoTo見たら、この複雑さをどうやってコントロールするかっていうのってやっぱすごい難しいなと思って。
やっぱその複雑さのコントロールの仕方によって作れる、結局規模感みたいなものが変わってくるよねって思った時に、
そういうGoToだったり構造化プログラミングとかでもいいんですけど、やっぱソフトウェア、プログラミング言語の発展で表現力が上がり、
問題を分割操作できるようになるとかっていうことっていうのが、いかに我々にパワーを与えているのかってことを、
あの変換を見てまじまじと感じたんですよ。
GoToっていうものが深くあったんだよね、ガハハっていうレベルから、
GoToでコードを書くってことがどんだけ大変なことなのかってことがわかり、
じゃあ今自分たちのプログラミング言語、使っている言語っていうのはどういうふうな表現力を持っているんだろうかとか、
どういうことを考えないといけなくて、どういうことは考えなくていいようにしてあるのかっていうことが、
もっと身をもって体験できるようになったって感じはすごいしましたね。
だからあれですよね、DHHが出てきて、レールズが出てきてくれたおかげで、
なんかテーブルの設計だけ考えれば、あとはSTLとか考えなくていいじゃんとかって言ってたのと同じはず。
24:07
で、それってやっぱり何かをできなくしてるって話でもちろんあるなと思ってて、
GoToがやっぱり一番強いんですよね。何でもできるんで。
なんかそれこそ、どこまで広げていくのかわかんない。
ちょっと守りに振ると、PHPとかってメモリの管理とかまでは厳密にできないじゃないですか。
最初にメモリをこのぐらい確保して、そこに丸々型のデータ突っ込んで管理しますとかはできないんですよね。
それができないから安全だし、そこら辺意識しなくてとても便利だねではあるんですけど、
それができたほうが便利というか、それができないと話にならんみたいな場面ももちろんあるわけじゃないですか。
そういう意味で何かをしやすくするっていうよりかは何かをしにくくすることによって進化していったなみたいな感じがしたりとか。
そこら辺の下支えにあるのってやっぱりCPUとかメモリが安くなってるからだよね的な気もしたりとか。
そうですよね。Goとかだとエクセプションはなくて、エラーを戻してちゃんとそれをハンドリングしなさいねっていうことを。
ある種面倒だけど無理やりやらせている不自由さっていうものがソフトウェアの設計に影響を与えてるんだっていう風な見方ができると思ったりもするし。
そうですよね。
メモリ効率的な部分じゃないところで型付き言語を注目されてたりとかは、まさにそういう好んで制約を加えることによって表現力が上がってるような気もするしみたいなやつはありますよね。
ひらがなで喋るよりも漢字使えた方が楽じゃんみたいな。明らかにレコードのコスト高いけどなみたいな。
読めなくなる可能性もあるしね。覚えるもの増えるとかね。いろいろあるからね。
文字化けしやすくなりますしね、文字増える。
そうですね。SGISとかWIN32とかCPQ32とかいろいろ今一瞬頭の中に糸編の漢字がいっぱい出てくるとかね。いっぱいありましたからね、昔。
何の話をしてたんでしたっけ。
シンプルな設計ですね。シンプルな設計っていうの中には、カバレッジとか表現力数が縮小かってことがあるけど、それの裏を下支えしてるのは、昔のソフトウェアの作り方と現代においてはできることだったり違ったりするんで、そういう背景がありそうだよねっていう話をしてたって感じですね。
27:11
やべえ、30秒でまとめられるじゃんみたいな話を長くしちゃったみたいな気持ちになったけど、そこは気にせず行きましょう。
4とかFとかをGoToに書き換えるぐらいの時は頭の体操だみたいな、去年はその気持ちだったんですけど、いよいよ今年何でもかんでも自動で書き換えられるってなると、本当にメンテナンスしたくないなとか思ったりとかね。
制約の話で言うとプライベートとかプロテクテッドとかファイナルとか外してるんで、あそこら辺はマジで人間のための機能だなみたいな気がしましたね。
すみません、まとめた話を無理やり手つかんで広げたんですけど。
じゃあそろそろ次に行きますか。
第1部は後は第7章第8章とあるんですけど、次行きますか。第2部基準行きますか。
基準ですね、これは弱小ポッドテストだから問題ないと思ってるんですけど、第9章のこの本の中で僕が一番好きというと語弊があるな。
強く脳みそに刻まれているのが一つはここだなっていうのがあって。
えっとですね、第1章始まって2章目、最初の説のタイトルに絶対に嫉妬を出荷しないっていう風に書いてあって。
クソを投げつけるなみたいなこと書いてあるわけですよね。
ここ火力増し増しですげえなーって。
なんかこう出版社に高越とか指摘されないんだろうと思いながら、ここはもうとても大事なんでこの表現でいきますみたいな。
Fワードではないからな。
そうですね、確かに。
これね、SHITの真ん中の2つが不正字になってるアスタリスク2つになってて、ノーソンとかでコピペするとすげえボールドになるんですよね。
確かに現代っぽいですね。アスター付けるっていうのが流行りですからね。
SアスタースターTになってるんで。
ここはなんかすごい火力が高いねっていう、さっきのデファクタリング応援してたみたいな冗談として紹介してるわけではなくて、ここは身につまされるような気はしたんですよね。
30:09
なんかバグはダメとか、クソって連呼するのがちょっと嫌だったんであれなんですけど、バグはダメだよとかテストしてない関数はダメだよとか。
そこら辺は確かにこの本自体がキリストか倫理の話をしてる本なんで、わかるなっていうふうな感じなんですけど、だんだん詳細に対する依存はダメであるとか、不必要な結合はダメであるとか、ビジネスルールに含まれるデータベーススキーマはダメであるとか。
この言葉の切り取り方というか、どこまでを本当にダメ、信じられない、ありえない、絶対認めたくないっていう基準をどうやって置くかっていうのは、その人のプログラマーとしてのプロフェッショナリティーにすごい深く突き刺してくるなっていう気は。
ちょっとして、この言葉を好きとはなかなか言いづらいんですけど、すごい印象に残ってるなっていう感じでしたね。
これ、アイスブリックとかエクササイズみたいなのやると、どれくらいプログラミングに対して想像力があるかとか、どんな経験をしてきたかみたいなのが明らかになってきそうだなっていうのを、このレックされてるものを見て思ったりしましたね。
あとなんかここらへんは本当に言うはやすし、行うはかたしだなと思ってて。
そうですね。
いやー、誰でもあるよねって言ってでも笑いごとにしたくないじゃないですか。
笑いごとにしたくないけど、今GUIに含まれるSQLはって書いてあって、テンプレートの中に確かにSQL書いたことあるなとかね。
そこで引っかかりました。僕はそこはやったことないな。
あとこれはしょうがない部分もあるかもしれないけど、エロクワントがループされて、そこでシュッとリレーションを取るとSQLが発行されてるなみたいな気持ちになったりとかいうのを思い出しましたね。
それはあるな。確かにスタックトレースをたどっていったら、あれ?テンプレートっていうディレクトリからSQLが呼ばれてる?みたいな。
そこはね、ある種ララベルを使うっていうことをしたときにはしょうがないっちゃしょうがないってことだと思うんですけどね。
ここら辺はね、言い訳をするなっていう話と、言い訳をしないために普段からどうやって備えてるかっていう話の両面があるなと思ってて、ここは良い話だなって思って見てました。
33:00
だからその説の後ろの方に続いて、別の言い方をすればいい仕事をしようだっていう話があって。
そうなんだよな。
ハイライトしましたね。
だからやっぱり自分がやってる仕事に対して誇りを持つとか、誇りを持つためにはどういうような基準、期待みたいなものが必要なのか。
つまりこれをやっていないってことは期待されるよね。こういうことをしてるってことは期待されるよね。
そういうことを考えていくと、じゃあその時に良いプログラマー、良いソフトウェアエンジニア、良い○○っていう人はこういうことはしないよねみたいな大切りをしていくと、バグを放置してそのまま出さない。
テストを書いてないのはありえないとかいうのがいっぱい挙げられていくんだろうなって気がしていくし、そういう意味でもやっぱりみんな読んでほしい本だなという気持ちになるなって思ったりしました。
なんかまさにテスト書いてないとかそれTワダの前で同じこと言えんのってやつですよね。
そうですね。
イマジナリーTワダさんとかいると。
そう。書いてそうなんだよな。ちょっとコアテスト書かずにとかって言い訳しようとした瞬間にスッと。
サバナに連れ込まれる。
サバナに連れ込まれるから、よしじゃあちょっとAIもあるしテスト書くかみたいな感じでパッとなるから。
なんでですかね。Tワダさんってそんな恐ろしいプレッシャーのすごい人だと感じたことがないんだけど。
いやいや自分も実際そうなんだよな。
めちゃくちゃ真摯にアドバイスくれる人だなと思ってるんですけど。
面白い。
なんかだから三粒のTワダさんがその怖いかどうかっていうよりはあのミームの。
あのミームのね。
あのミームがなんか強制力があるみたいな感じですよ。
実際に会ってみるといい人ってやつですか。
なんかそういう言い方するとインターネットめんどくさい人たちをいっぱい追いかけるから。
