汚いコードを書こう

30,795 文字

Twitch ☕ ssh terminal.shop 📘 Carson’s book: 🧠 Grug Brained ...

さて、今日のスタンドアップをどう紹介すればいいかよくわからないんですが、TJ、録画してますか？あ、録画してますね。もう録画してたんですね。あ、録画してるんですね。分かりました。妻から電話がかかってきてます。もちろん、彼女が来るでしょうね。みんな、彼女を通話に入れて、話し合ってください。ホットマイクでいけます。何について話してるんですか、みんな？何について話してるんですか？やることがあるので。
今日は何をするんですか？まあ、私の場合、QAで少し詰まってます。彼らは先月末までにすべて終わらせられると言ってたんですが、案の定、4が5になってしまって、そんな状況です。ほとんど彼らのせいで詰まってます。ドキュメントの更新はしてますが、それだけです。私からの報告は以上です。
Carson、私は学生の採点に追われていて、GitHub Actionsの仕組みを理解しようとしています。そして分からないんです。長い道のりになりそうです。ポイントがたくさんあります。今は掲示板にたくさんのポイントが載ってます。最近はみんなAを取るんじゃないんですか？何があったんですか？
ええ、そうですね。そうならないように気をつけてるんですが、簡単なんです。簡単なんです。見てください、彼らがAIを使ってレポートを書くなら、AIを使って採点すればいいんです。私は子供たちにこう言ってます。子供たちにこう言ってます。「見てください、私はかなり良いプログラマーで、プログラミングの仕方を教えることができます」と。
さて、ここにいます。さて、ここにいます。さて、準備完了です。Prime、またね。さて、みんなもう時間を過ごしましたね。ねえ、私にはブロッカーがありません。ブロッカーがありません。ブロッカーがない？すごいですね。私は非常に詰まってます。だから何も完了してないんです。3週間コードを提出してない理由を説明してもらえますか？設定をしていて、たくさんコミットしてます。
新しいArch環境の設定ばかりです。つまり、設定をこれほどたくさんコミットして詰まりが解消されてるんです。まだ斧を研いでるんですね。斧を研いでます。この時点でこの斧がどれほど鋭いか、あなたには想像もつかないでしょう。
今日は特別ゲストがいます。Montana State大学の教授で、HTMXの作者であるCarson Grossさんです。これはWebの、どう説明すればいいでしょうか？インターネットの人気トレンドを全て取って、その逆をやることです。
そしてMSUでは、システムプログラミング、データベース、オペレーティングシステムを教えています。これで合ってますか？コンパイラを教えています。OSは教えてません。なるほど。OSを教えたくないんです。その気持ちはわかります。
つまり、組み込みシステムの古典的な人がWebフレームワークを書いてるということで、私たちが招待したのはそういう人です。そして通常、私たちにはTeeがいます。Teeは紹介不要です。
ちなみに彼はストリームもしてます。そしてCasey Miratori、素晴らしいゲーム開発者でcomputerenhanced.comの。そうですよね、Casey？そうですよね？その通りです。正しいです。さて、また熱心な鳥愛好家でもあります。熱心な鳥愛好家、鳥類学のスペシャリストです。その通りです。
多くの人がなぜTrashDevが今日いないのか疑問に思ってます。それはCarsonがワンパスワードを解明して、Trashが自分のアカウントからロックアウトされているからです。
そうです。Trashがすべてのパスワードのリセットに成功すれば、番組に戻ってきます。残念ながら彼はアルファベット順で進める必要があり、ワンパスワードを取り戻すためにすべてのウェブサイトを順番に処理する必要があります。trash dollar sign oneです。
さて、今日は特別なトピックを議論します。これは本当にクリーンコードのビザロワールドです。Carson Grossによる「コーディング・ダーティ」です。Carson、コーディング・ダーティとは何か、簡単に紹介してもらい、なぜ人々がこのようなコーディング方法を検討すべきかについて、あなたの立場を教えてください。
まあ、呼んでくれてありがとうございます。コーディング・ダーティは長い間私の頭の中にあったエッセイでした。
あなた方はクリーンコードの人であるUncle Bobと話したことがありますね。そして、そのクリーンコードのエッセイ、というか本は、アジャイルの世界から出てきたものです。私が最初にプロとしてプログラミングを始めた時、Javaが、そうですね、そこにあります。
Javaがちょうど大きなものになり始めていました。それで私はパターンやアジャイルマニフェスト、そしてテスト駆動開発といったもので育ちました。そうしたものの多くが私がいた世界に本当に組み込まれていました。それで、ついに、いつも何かが私にはしっくりこないものがありました。
それで、ついに私は「よし、エッセイを書いて、反対の方向で行ってみよう」と思いました。そして、Uncle Bobについて言わなければならないのは、彼はTwitterで本当に良いスポーツマンだったということです。だから私は彼について悪いことを言うつもりはありません。彼はここ数日Twitterでただのクールな人でした。
しかし、あなた方が彼をクリーンコードについて話すために呼んだ時、私が注目したいくつかのことがあり、私は「このエッセイを書かなければならない」と思いました。私のコードの書き方について話すエッセイを。
そしてエッセイで私が言っているのは、あなたがこのようにコードを書く必要があると言っているのではないということです。なぜなら私のコードの書き方が必ずしもあなたのコードの書き方ではないからです。しかしそれでいいんです。でも私が示したいのは、私はかなり成功したプログラミングキャリアを持っていて、クリーンコードが提案するものとはかなり異なることをしているということです。
私がエッセイで本当に焦点を当てている3つのことがあります。第一に、メソッドは大きくてもいいと思います。実際には非常に大きなメソッドでも問題ありません。そうです、その通りです。私は大きなメソッドが好きです。
そして、私はユニットテストの大ファンではありません。大ファンではないと言いたくないのですが、開発を駆動するためにユニットテストを使わないと言った方がいいでしょう。
そして最後に言いたいのは、特にJavaの世界で、そしてこれはRustや他の言語、TypeScriptなどでもある程度当てはまるようですが、しばしばクラスが多すぎると思います。エンドユーザーに多くのものを露出させすぎて、すべてを分解しようとして、過度にアーキテクチャされたコードにつながる傾向があると思います。
例えば「クラスは一貫性があるべき」というのは、非常に賢い人々が言うことで、それは正しいです。しかし一貫性を気にしすぎて、すべての小さなことが独自のクラスである必要があると考えると、このようなコードの泥沼に陥ってしまいます。
これらが私が話したい大きな3つのポイントです。そして、お望みなら、それぞれについて詳しく掘り下げて話すことができます。
TJが本を持ってますね。後で出そうと待ってました。一冊持っているなら、もう一冊も持たなければなりません。Hypermedia Systems、みんな。それはいい本です。
本当にいいです。優秀なハードカバーです。ちなみに美しいカバーですね。Amazonで入手可能です。これを見てください。内側も素晴らしいです。嘘じゃなく、表紙から裏表紙まで読みました。ありがとうございます。感謝します。
そうですね。それは本です。後で小道具として出そうと待ってたんですが、あなたがそれを引き出したのがバレてしまいました。
後でもう一度小道具として出しましょう。この本についてもっと知りたいので。でも今は最適なタイミングではないかもしれません。コードのことを話すことになっていたので。それで後でもう一度出しましょう。それを手元に置いておいてください。戻ってきます。スタンドアップ言語で戻ってきます。すみません。戻ってきます。
オフラインにしません。スタンドアップに残します。オンラインに保ちます。そうです。オンラインに保つのが私たちのゲームの名前です。
私が言いたいのは、これは公式の引用符付きクリーンコードの講義や本で断固として述べられていることから大きく逸脱しているということです。より大きな関数を持つということですよね。より大きな関数は極めて否定的に描かれているもののようで、なぜそうなのかすぐには明確ではありません。
多くのことと同様に、経験的な証拠は与えられず、実際の例も与えられません。つまり、通常、アーキテクチャのことをやろうとするなら（私は過去に簡潔にアーキテクチャについて講義をしたことがありますが、私が時間の大部分を費やして話していることではありません）、アーキテクチャのことをやろうとするなら、少なくとも「これを書くことができるすべての方法を見てみよう、それぞれを見て利益は何か、欠点は何かを見て、いくつかの異なることを試してみよう」というように準備すべきです。
この種の特性を持つ関数を見てみましょう。この種の特性を持つ関数を見てみましょう。そして大きくしたり小さくしたりした時、どのように見えるかを見てみましょう。そうしたことは何も起こりません。ただ、「小さくあるべきです。次のこと」というだけです。
すべて語彙だけです。説明的なだけで、実際にコードは示されません。そして実際にコードを見る時、クリーンコードの例のコードなどは、本当にひどいです。これについて批判したいことがたくさんあります。私はクリーンコードのひどいパフォーマンスビデオのために小さなセグメントを一つ選んで、「これがひどいと思う理由はすべてここにあります」と言いました。
しかし、それは一つのスニペットに過ぎません。すべてについてそれができます。それで、あなたは実際にエッセイで実際の研究を引用しましたね。コードコンプリートからの研究で、彼らがそれを調べて、あなたが言っていることでは、より大きな関数は実際には経験的証拠がそれほど反対していないことを発見したということですか。むしろ、わずかにそれらに有利だったということですか？
そうです。私はいくつかを引用しています。メソッドの長さについて話している古い本であるクリーンコードがあり、彼らが通った研究では、実際にはより長いメソッドの方が高品質であり、コード1行あたりのバグ行数が少ないことが示唆されました。これは合理的な指標です。
より最近の論文があり、誰かが私に投げつけてきました。私が「長いメソッドは問題ない」と言っていたら、彼らは「まあ、私たちには」と言って、私がこの古い本を引用していました。その本で引用されている研究のほとんどは60年代と70年代のものなので、少し古いです。そして彼らは別のエッセイを私に投げつけて、「短いメソッドの方が良い」と言いました。
学者に論文を投げつけてはいけません。彼らはそれを読まないと思っているのです。私は論文を読みに行きました。そしてその論文を読むと、まず第一に、この論文はクリーンコードが推奨する4〜5行よりもはるかに長い最大20行のメソッドが理想的だと言っていました。
そして実際に読んで統計を見ると、彼らが使っていた統計で、関数サイズとの相関が最も少なかったのは、関数ごとのバグでした。そして私は「それが唯一重要なものです。なぜなら他のものは変更しやすさのようなものだったからです」と思いました。
まあ、すべてを一つのメソッドに入れれば、もちろんそれはより変更しやすくなります。なぜならすべてがそこにあるからです。また、10倍の数の関数があれば、おそらく関数ごとのバグは少なくなるでしょうが、それはバグが少ないということを意味しません。
私がそれほど怠惰でなければ、これらの人々からデータセットを取得して計算をして、「これは大きな関数でコード1行あたりのバグが少ないと言っているように見える」と言うでしょう。
そしてそのセクションでも出ています。このすべての内容はhtmx.orgのエッセイページにあります。コーディング・ダーティエッセイです。そして私はChromeやReddit、IntelliJのような、非常に高い品質レベルを持つこれらすべての大きく成功したソフトウェアプロジェクトを調べます。そしてそれらすべてに大きな関数があります。何百行、高い、100行近いかそれ以上の関数があります。
それで私は、繰り返しますが、長い関数を持たなければならないと言いたいわけではありませんが、長い関数が悪くないという良い証拠があり、おそらく良いとさえ言えると思います。
そして私は大きな関数に対して一つの哲学的な議論をします。関数が大きい時、重要な関数が大きい時、それは物理的な、美的なヒントです。これは重要だということです。重要でない100行の関数はありません。そして、すべてを5行の関数の束に分割しようとすると、コードモジュール内で重要性をかなり薄めてしまいます。
そしてそれは良くないと思います。メソッドを抽出することでコードの再利用が見つかるなら、それは確かに良いことです。そして今度はそれをする理由ができました。でもそうでなければ、小さな関数それ自体のためだけでは、ソフトウェアを書くのに良いアプローチではないと思います。私がそれをする方法ではありません。
また他の側面もあると思います。長い関数では、プログラマーが理解しやすいということです。なぜなら私は上から下へ読むだけで、この関数が正確に何をするかを見ることができるからです。時々止まって、具体的な内容を正確に知らないかもしれない別の関数を見に行く必要がありません。
そして、多くのコンテキストがある場合、デバッグも簡単です。コンテキストの内容でたくさんの引数を渡し回していることに気づいたら、すべてそこにあって問題ありません。
それも真実だと思います。すみません、暑いです。この愚かなローブを脱がなければなりません。大丈夫です。一人でローブします。大丈夫です。私は脱ぐ準備ができていません。
もう一つ、私がGolangで気づいたことは、Golangでは何かがリストを反復処理する時を見るのが簡単だということです。なぜなら彼らは偶然にリストの反復処理をする派手な方法を持っていないからです。そして彼らの考えの一つは、何かが高価なら、それを明白にすべきだということです。ループに入れます。すべてのものに対してそれを行います。それで「ああ、すべてのものに対してそれを行う」となります。
そして私は自分自身について発見したのは、Neovimのような大きな関数をたくさん持っている時です。そのうちのいくつかはそうでなければいいと思いますが、まあ、問題ありません。そしてNeovimもかなり成功したソフトウェアだと言えるでしょう。
でもforループが見えます。この関数がすべてのものに対して呼び出されることがわかります。それはプログラマーとして実際に非常に有用な情報です。そして「ああ、その関数はすべての要素に対して、またはすべての要素に対して2回呼び出される」などと言えます。ネストしたforループがあると突然「ああ、今度は何かについて本当に心配する必要がある」となります。
関数と関数であれば、おそらくそうではありません。どこかでネットワークに接続する場合は、まあ、それは別の話です。しかし、変更しやすさについて話していました。大きな関数には、コードが変更されるという仮定（アーキテクチャを考える時に考慮すべき最も重要なこと）を語る追加の要素があると思います。
通常、アーキテクチャにとって最も重要なことは、長期的には異なる決定をしなければならないという事実にどのように対処するかです。短期的なアーキテクチャは、この機能が全体的にうまく動作するかどうかについてです。しかし長期的には、「ああ、これを本当にやる必要がある」または「ああ、いくつかの違いがあるこのプラットフォームに移植する必要がある」、または「これらの機能を追加したい」など、異なる決定をする我々をサポートするかどうかです。
大きな関数の一つの特徴は、小さな関数を持っている場合、これらの小さな関数への変更を行うたびに、その関数を誰が呼び出すかを知るために、ほとんどツールからの支援が必要になることです。なぜなら、その動作について何かを変更すると、漏洩の可能性がある場合に問題になる可能性があるからです。
そしてそれを持たないことを保証するのは非常に困難です。SOLIDやこれらのことに本当にのめり込んでいる人々は、何らかの方法で関数型プログラマーでもあるかのように、副作用がないかのように振る舞いますが、彼らは決してそのような方法では書きません。オブジェクトは常に変更されています。
それで実際にこの関数を見ると、SOLIDコードベースやそのようなものでは、これらの小さな関数に副作用がないことは非常にまれです。その結果、一つの大きな関数があり、その中央のすべてのステップを見ているだけなら、他の誰かがこの関数の中央を呼び出しているかどうか自問する必要はありません。なぜならラベルとロングジャンプがあるとか、何かクレイジーなことが起こっているとかでない限り、それは基本的に不可能だからです。
誰もそこに入ってくることはできないとわかります。彼らは上から始めなければならないとわかります。これらの他の小さなものがすべてあり、それがこの操作の実行方法であるなら、1000行の関数の代わりに、10個の100行の関数があります。突然、それらのそれぞれについて、他の誰かが私が変更しようとしているこの関数を他の何かのために使用したかどうかを覚えておく必要があります。それとも、それをそのままにして、それをコピーして新しい関数を作るべきでしょうか？それはさらに悪いです。なぜなら今度は非常に似ているが一つを変更した何かの2つのコピーがあるからです。
他に部分を取り出す理由がない場合、関数を大きく保つことは、読みやすいからだけでなく、変更しやすく、変更に対する信頼を持ちやすいかもしれないから、多くの理由で実際に重要です。
テストもしやすいです。なぜならテストしているのはその関数だけだからです。「ああ、待って。まずい。この関数を他で使用したすべての場所でこの関数のカバレッジテストを持っていたことを願う。なぜなら働き方を変更したばかりだから」とはなりません。
私が大きな関数を好む理由は少し異なります。多くの小さな関数と関連して、構築時に渡される多くの制御の逆転があることが多いからです。これと一緒に呼び出すという感じで、この種の逆さまのツリー効果が起こります。
関数にジャンプして、それが4つの他の関数を呼び出します。それがやることのすべてです。関数A、B、Cを呼び出すだけです。それで「これは理解できるけど」となり、それが戦略パターンの後ろにあります。それで「この実装は何ですか？」となります。その実装にジャンプして、それを見つける必要があり、3つの異なるバージョンがあります。
それで「どれを見ているのか？これを見ています」となり、このような段階的な釘のようなドリルダウンをします。2つ、3つ、4つの関数を跳び回って終わるまでに、私は元々いた最初の関数を忘れ始めます。
私は比較的短いコンテキストウィンドウを持っています。どこにいたかを忘れるまでに約4つの関数に入ることができます。どうやってここに来たのか？それで私は単にVimでcontrol Oをスパムして後ろに跳ぼうとして、「オーケー、オーケー、戻ってきた。戻ってきた」となります。それで前に進んで、前に進んで、前に進んで、一度ジャンプして、また全部忘れました。待って。
2回のジャンプです。なぜならこのホッピングビジネスに入るからです。LSPがこれを悪化させたと思います。なぜならLSPが短い関数のナビゲーションを簡単にしたからです。つまり、19の関数呼び出しを連続して覚えるのが非常に得意な人々（私はそのような人ではありません）にとって、非常に簡単にナビゲートできるので、追加し続けるのが非常に簡単だからです。
以前はおそらく少し難しかったでしょう。ファイルを覚えて、ファジーファイルを見つけて、それから関数を検索して、関数にジャンプする必要がありました。支払われたエディターにいる場合を除き、太陽の下のすべての言語でそれを簡単にできませんでした。明らかにJavaはそれへの多くのアクセスを持っていましたが、それでも私は小さな関数をうまく理解できません。
私がどこに向かっていたかの軌跡を失うのは純粋に私です。戦略パターンを投げ込むと、私はゲームを失って、プリント文でたくさんデバッグしなければなりません。なぜならそれがコンテキストを含む唯一の方法のように感じるからです。実際、ステップデバッグは、その時点で私にとって歩き回るのにも困難になりすぎるからです。
私は彼らに対して異なる種類の問題を抱えています。私が先日Twitterで言ったことの一つは、抽象化がコストフリーであると偽るのをやめる必要があるということです。そうではありません。何かを抽象的にするたびに、クラスを叩くたびに、if文を取って動的ディスパッチに変えるたびに（今日作ったジョークです）、それをする良い理由があるかもしれません。決してしてはいけないと言っているのではありません。でもそれがコストフリーだと偽ってはいけません。
覚えなければならない名前の束があります。理解しなければならないがらくたの束があります。誰が何をしているのか、動的タイプは何なのか。それは理解するのがずっと難しくなります。
そして良い古いループ、ifとループは、まあ、彼らは彼らがすることをして、理解しやすいです。それで、ソフトウェアに過度に複雑なソリューションを作成することに脅されてはいけません。なぜなら私たちは、この一つのツール抽象化に慣れているからです。
何かが少し醜く見え始めるたびに、「よし、それに抽象化を投げつけよう」となります。そしてそれは時々物事を大幅に悪化させることができます。でも最終製品を本当にきれいに見せます。4行のコードがあって、すべてをするようなこの瞬間があります。
だからすべてのきれいさの追求を理解します。その4行を見て、「設定して、実行させて、少し印刷して、優雅にクローズ」となります。そして私は自分の背中を叩いて、「これは美しい」と言います。それで何かをしなければならず、それからひどくなります。
すべてのこの長い関数についての議論は、長い関数があなたにとってうまく機能していると感じるなら、おそらくそうだという事実をサポートするためだけであることは指摘する価値があります。明らかに、私もたくさんの短い関数を書きます。だから短い関数が短いことを批判することは決してないでしょう。それがその関数にとって適切な長さなら、素晴らしいです。
だからそれはもっと関数はすべてのサイズを取るということです。関数のファットシェイミングをやめましょう。
どんなサイズでも美しい。どんなサイズでも美しいというのが、関数について私がいる場所です。
抽象化について持ち出したので、もう一つ指摘したいことがあります。これらのことの教訓的な、または教育学的なバージョンで、人々がこれらの主張をしていて（繰り返しますが、それらは決して証明されません）、「まあ、すべてのこれらの小さな関数を持つのが良い理由は、良い名前を付けるだけで、コードを書くだけで、名前がそこにある」と言うでしょう。
これは完全に間違いです。そしてそれが完全に間違いである理由は、もしそれが真実なら、それらの名前がプログラミング言語になるからです。そうでしょう？もし名前が実際にコードがどのように動作するかを理解するために必要なすべてを本当に捉えることができるなら、それがプログラミング言語になるでしょう。
それがプログラミング言語でない理由は、実際に5行や6行の関数であっても関数に名前を付けるたびに、それが実際に行ったことについて何かの情報を失うからです。処理しなかったエッジケース、そこにあったバグ、このコードベースでは必要ないとわかっているので簡略化しているもの。
名前は関数と同じ長さではないので、その名前から何かが除外されます。関数は言語にあります。それは我々が知っているそれを表現する最も簡潔な方法か、さもなければ異なる言語を使っているでしょう。
それをするとき、そして階層の上にそれをするとき、プログラムが実際に何をしているかの完全に間違った感覚を作成しています。何かを読んで、あなたの脳はそれがこの関数がすることだと思いますが、実際にはこの関数は他の多くのことをして、名前を読んだときに仮定していた多くのことはしません。
だからそれがこの問題への簡単な答えではない理由です。私たちは再利用のためのプログラミング、管理のために機能的分解が必要だからです。ある時点で関数が100,000行の長さなら、管理するのはかなり困難になるでしょう。
だから機能的分解が必要で、名前を付ける必要があります。なぜならそれが人間としてできることのすべてだからです。それが何かを抽象化できる唯一の方法は、名前を付けることです。
でも、それがこれらの問題への解決策ではないことを覚えておく必要があります。ここにバグが潜んでいるかという問題、私が考えていた何かをしないかという問題、この名前が私を他のことが起こっていると思わせて誤解させるかという問題は解決しません。名前は理解の代替ではありません。
どれだけ優秀でも、完璧に捉える名前を作らなかったのはプログラマーの失敗ではありません。もしできるなら、あなたは世界最高の言語デザイナーになるでしょう。だからそれは当然のことです。だからそれを内在化することが重要だと思います。
さて、TJから聞く必要があります。TJはバスローブを着て黙って座っています。
実際に彼は今ホットタブにいると思います。何が起こっているか分かりません。この素晴らしい情報をすべて吸収しているだけです。
分割について言おうとしていたことで、あなたがPrimeについて少し触れたと思いますが、少し詳しく説明すると、いくらか関連しているが正確には同じではないものを一つの抽象化の下に押し込む誘惑があることがあります。それからこのトップレベル関数に37のスイッチを渡して、すべてのことをするかもしれません。
とにかく一つの方法でしか構築しないかもしれません。これは面白いです。後で必要になると思って、これらすべてのクレイジーで複雑なオプションを誤って書いてしまったかもしれませんが、実際には決してしません。
実際には一つのコールサイトしかありません。これはかなりよく起こります。なぜなら後で必要になると思っているからですが、決してしません。
会社が閉鎖して、6ヶ月早く出荷できていたかもしれないし、会社が存在していたかもしれません。私にはそれが起こったことはありません。でもたぶんありました。
とにかく、そうすることもあるし、すべてのこの追加のコンテキストを渡して、すべての条件をスイッチオフして、これらの内側ですべてを理解するのがずっと簡単だったでしょう。上から下に書いて、制御フローがどのように見えるかを見ることができて、複雑なケースのいくつかについては、それを自分のために綴る方がずっと簡単です。
if文が必要以上のものであることもあります。いつもポリモーフィズムが必要というわけではありません。if文でいこう、は完全に有効です。
if文はただのif文であることもあります。時にはただif文を書くだけです、みんな。大丈夫です。
さて、これを少しタイトに保つために、しばしば私たちは長すぎる議論に終わってしまうので、もう一つあります。スタンドアップで長すぎることはできません。これは文字通り全体です。まあ、Carsonは行かなければならないかもしれません。
ああ、いえ、大丈夫です。私たちは、私たちは一般的にエピソードを30分に保とうとしていることを覚えようとしているだけです。それは本当ではありません。一つのトピックで誤って1時間にしたくありません。
私もです。分かりました、Prime、リラックスして。1時間でスロットしてます、相棒。問題は何かというと、Prime、あなたはバスローブを着ていないか、バスローブメンタリティを持っていません。
バスローブエナジーを持っていません。ビッグバスローブがあなたを狙っています、Prime。YouTube、これを1時間にしたい場合はコメントを残してください。私を1時間見たい場合はコメントを残してください。
分かりました。まあ、たぶん私が間違っているかもしれません。でも真面目な話、私があなたに対して持っている本当の質問は、開発を駆動する手段としてユニットテストが好きではないと言ったからです。
私の唯一の反論は、一度書くには複雑すぎると感じる機能を駆動できる任意の形式のテストが本当に好きだということです。つまり、要素のリストを合計するように頼まれただけなら、テストしません。ただしません。forループを書いて物を合計します。
それが私がやることです。だから単にテストしないロジックがたくさんあります。一発で書けて、そこにバグがあることになっても、それは非常に簡単です。あまり心配する必要がないことです。
でも時々、これは実際にかなり複雑な状態変換で、実行するのも複雑だという状況に入ることがあります。
だからこれをユニットテストにしたいのです。ユニットテストを介してこれの開発を駆動したいのです。TDDが大好きだから、または最初にテストを書いているからではありません。悪い開発サイクルを持ちたくないだけです。
それが、ユニットテストを使用しないでくださいとあなたが言ったことに対する私の唯一の防御または反対で、複雑すぎる時の実装側のためにそれが好きなだけです。
ええ、私は、アンチであるように見えてくるのは常に危険です。私はテストの大ファンです。私が言う時に難しいのは、ユニットとは何かという言語です。そして人々はそれをただ何でも意味すると言うでしょう。すべてがユニットテストなら、何もユニットテストではないタイプの状況です。
それは私の全製品です。それは一つのユニットです。それは私たちが持っている最小のユニットです。これらのことはしばしば定義の周りの誤解に陥ることがあります。それはただインターネットです。なぜ他にここにいるのでしょうか？正直に言って、定義について議論しないなら。
でも私が言いたいのは、TDEとユニットテストの大ファンではないと言う時、私はあなたが話していた元の意味でそれを意味しています。問題への解決策を書いていて、一つのメソッドを書いて、そのメソッドを徹底的にテストして、それから別のメソッドを書いて、そのメソッドを徹底的にテストして、それから最終的に「よし、今度は解決策ができた。なぜならすべてのメソッドが私が期待することを正確にするから」となります。それから私が統合テストと呼ぶようなものを書くかもしれません。3つか4つのことを呼び出すかもしれない、より高いレベルのメソッドを呼び出すテストです。
大きな関数のファンなら、本当にユニットはありません。TDD支援者によって典型的に使われる方法では、少なくとも私の意見では。
私が好むことは、そして私はこれはあなたが話していることに近づいていると思いますが、これの多くはソフトウェア開発サイクルのどこにいるかに依存します。
最初に始める時、解決策が何かまったく分かりません。典型的に、新しい機能なら、ただ分からないのです。概念を理解していません。ドメインがどのように見えるかを理解していません。APIがどのように見えるべきかを理解していません。だから遊び回って、核となるアイデアがここにあるものを見つける必要があります。
私のGrugエッセイで、私はそれをカットポイントと呼んでいます。「よし、これがAPIです。これがこのことがやることです」というように見つけるのです。それから私はそれを徹底的にテストすると言うでしょう。これはPrimeが話していることに近づいていて、本当にこれを固める必要があるところです。
でも私は関数を見て個々の関数を必ずしもテストするつもりはありません。代わりに、より高いレベルの私が再び統合テストと呼ぶもの、このシステムのより高いレベルのAPIに焦点を当てるつもりです。それからそれを徹底的にテストするつもりです。
それをしている時に、できる限りコーナーケースをすべて取得しようとします。それが一つのアプローチです。
TDDが意味をなす時があります。本当に小さな機能を巨大な既存のコードベースに追加する場合など。「既存のユニットテストのセットはありますか？はい。よし、その一つの小さな機能のためにユニットテストをしよう」。
そしてそれにユニットテストがない場合、その機能を追加する前にこれらの統合テストに戻って追加する必要があるかもしれません。物事を台無しにしていないことを確認するために。
だからそれは推測で、これは最初に言ったことに戻りますが、コーディングへの思想的アプローチのようなものがあります。「これをして」「いいえ、多くのことは状況的です」と言うようなものです。誰も「場合によります」と聞きたがりませんが、そうなのです。
オブジェクト指向プログラミング対関数型プログラミングのようなものに依存します。まあ、関数型コードベースに入る場合、その上にオブジェクト指向プログラミングを押し付けません。
関数型プログラマーになり、その逆もしかりです。多くのコードがある場合、コードベースとバイブマッチしないと、ただの災難になって物事を悪化させます。
このアドバイスの多くが思想的すぎて、適用しすぎるのが簡単だということです。それが私の大きなメタポイントです。多くの場合に悪くないアドバイスがたくさんありますが、あまりにも思想的で、適用しすぎるのがあまりにも簡単です。
焦点を間違った場所に置くことがあります。例えばオブジェクト指向プログラミングについて私がよく言うのは、プログラミングしているうちにオブジェクトになることがあるかもしれません。なぜならそれらが発生する自然な場所を見つけるからです。
少なくとも私の意見では、教える方法の問題は、プログラマーがオブジェクトを作成する必要があることに過度に焦点を合わせる状況に終わることです。
それは今や彼らの頭の中でそれ自体が目的となったアクティビティのようになっています。でもオブジェクトのためのオブジェクトは何もしません。コードベースにとって有益な特定の構造を取る場合にのみ意味があります。
だからそれは焦点が問題であるそれらのものの一つです。私たちが言っていたように、時々この関数は長すぎたという良いアドバイスかもしれません。より小さな関数に分解すべきです。それは非常に真実かもしれません。非常に間違っているかもしれません。
ポイントは指標が何かを学ぶことです。この時点でこれが欲しいですか？それは良いプログラマーになることを学ぶことの一部です。
「ただこのルールです」と言う人は誰でも通常間違っています。「これを一度もしてはいけない」と言えるほど悪いものがない限り。
私は三項演算子をネストしません。三項演算子が好きでも、三項演算子をネストしません。だからそれはおそらく安全に言えるものです。
常に一つあって、それが安全なものです。repeat untilも。repeat untilは悪魔のループです。do whileは主のループです。非常に明白です。
Caseyの「オブジェクトのためのオブジェクトは何もしない」という発言に一つだけ不満があります。Q2で大幅なパフォーマンス改善をする機会を与えてくれます。だからCaseyのように少し大きく考える必要があります。「ああ、後でこれらのオブジェクトを削除できる」と考える必要があります。
スピードアップ、来たれ。これは休暇中に何をするかの計画が見えますね。
まさに。これはシリコンバレーマインドセットです。私やCaseyのようにバスローブマックスしていなければ、理解できません。でも大丈夫です。
さて、ユニットテスト全体についてのあなたのCarsonとの話もあり、この全体を少しダブルクリックするために、私は「ユニット」という用語を使いますが、実際に私の頭の中では本当に2つの側面しかありません。
エンドツーエンドがあります。実際にプログラム全体を起動して、全体を完全にブラックボックス化するか、簡単な起動と実行を試みてユニットテストして、それを文字通り一つの関数だけでなく、ユニットと呼んでいるだけです。多くの関数かもしれません。多くの関数を呼び出す関数かもしれません。
そして、関数的、統合の違いがわからないということを知っています。ユニットがいつ関数的になり、関数的がいつ統合になり、統合がいつエンドツーエンドテストになるかがわからないのです。全体があり、それから離散的なユニットがあるという考えが好きなだけです。それだけです。
対戦相手のものを悪く見せたい時に用語の違いを使います。まさに。それがイライラするところです。あなたがそこで書いていたものを見てください。それは機能テストです、man。真のユニットテストはまだ試されていません。みたいな。
そして一度彼らをそれで捕まえて、すぐに勝つことができます。再び、あなたはこれでバスローブマックスしていません、Prime。たぶんそれが私の問題で、バスローブライフを生きてこなかったからで、一度生きれば心の新しい部分がたくさん開くでしょう。
初めてLSDを取るようなものですが、すべての結果なしです。ただ心を開く経験です。私はバスローブを開く経験を求めています。それが私が求めているすべてです。これは私がLSDに最も近づくものです。
エンドツーエンドテストについて言うべきことが一つあります。エンドツーエンドテストが大好きで、本当に重要ですが、エンドツーエンドテストをやりすぎないことについて超規律的でなければならない領域です。
エンドツーエンドテストスイートが大きくなりすぎた複数の会社にいたことがあります。そしてGrug Brainエッセイにはテストについてのセクションがあり、やりすぎてはいけないと述べています。エンドツーエンドテストスイートが必要ですが、それは宗教的に維持される必要があり、アプリで最も重要なことに焦点を当てなければなりません。
あまりにも多く追加すると、非決定的になり、壊れ始めて、人々が注意を払わなくなります。そして持つことができる最高の炭鉱のカナリアです。だからそのバランスがあります。「ああ、エンドツーエンドテストは良い。もっと持とう」となりますが、「いいえ、いいえ、これについてバランスを取らなければならない。エンドツーエンドテストスイートをやりすぎると、価値が少なくなります」。そしてそれは理解しなければならない奇妙なことの一つです。
そして何らかのデータやサービスリファクタリングに関しても、それらは不釣り合いに困難です。それらのような任意の、それは作業がずっと多いです。
大きなシステムリファクタリングがある時、「よし、システム全体を壊してない」ことにとって絶対に重要になることがあります。でもあまりにも多くあったり、十分でなかったりすると、困難なバランスです。
または間違った出力をテストしていることもあります。内部状態について75のことをアサートしようとするのは本当に簡単で、「ああ、今度は本当にそれにロックインされている。変更をして動作が同じだとアサートするのは非常に困難になる。なぜなら何が実際に動作で何がものの最後に保持したランダムなものかが明確ではないから」。
これはAI生成テストで本当にイライラすることの一つです。デモと実際に私が人々がやっているのを見た両方で、少なくとも私が見たすべてのものから、彼らは物の内部状態について本当にたくさんアサートして、統合に密結合しているということです。そして「何かを変更したい時はいつでも、すべてのテストが毎回壊れる。変更するたびにそれらを壊すので、システムがまだ動作するという良い感情を得ることはできない」。
AIがそれをしないでリードすべきなので、それは残念です。「実際に画面を視覚的に解析できるものがある。なぜ望んだ場合でも正しいグラフィカル出力をプログラムが生成したかどうかを見る代わりに、内部状態をテストしているのか？」のようです。それは非常に有益な機能になるでしょう。
だからAIがそこに到達することを願っています。または誰かがすでにそうしているが、それは広く普及していないだけです。AIテストが実際に本当に役立つポイントに到達するために。
「ああ、普通に実行した時のプログラムの様子がここにある。それを覚えて、これをするのをやめた時を教えて」のようにできるだけです。うまくいけば、ある時点でかなりうまくそれができるでしょう。
それに対するクールなソリューションがいくつかあり、以前に使ったことがありますが、それらはAIではありません。他のことをします。でも私が言っているのは、OCRやエッジ検出のようなものがあったので、以前にグラフィカルテストができなかったわけではありませんが、人々が作成するのがずっと速くなるでしょう。何でも作成できるでしょう。
ゲームでは、最終製品のテストを作成する方法という問題がよくあります。どのように見えるべきかを知るのは難しいからです。まあ、AIはゲームをプレイして、いくつかのものを見つけて、物を見るようなことを簡単にできるでしょう。「ああ、そのオブジェクトが落ちた。そのものから落ちるはずではない」。
確実にそうなるとは言えませんが、そうなる可能性があるAIが助けることができる以前はテストを作成するのが非常に困難だったもののようなことを想像できます。
ビジネス、制約と結果が変わることがあるが、実際の実際のビジネス結果、ビジネスロジック結果に関連するテストを書くことは良いと思います。なぜならそれが変われば、テストを削除しても良いからです。「ああ、これで税金を計算することになっていたが、ルールが変わって計算しなくなった」と確実にわかります。
「ええ、クール。よし、テストを削除する必要がある。なぜなら今嘘をついているから」となります。それは良いことです。そして多くの場合、人々は実際にはシステムの要件や制約をテストしません。頭に浮かんだことやランダムな境界点をテストするだけです。
それは私が作るもう一つの重要なポイントです。Grug Brainエッセイにはありませんが、コーディング・ダーティエッセイにあります。テストスイートは独自の質量を持ち、あまりにも多くのテストがある場合、気をつけなければなりません。なぜならテストは一種のあなたを強制して、コミットされているようなもので、「多くのがらくたを壊すことになるので、この変更をすることができない」となります。
だから私が言うのは、時々単にユニットテストを捨てて、高レベルのテストを保持する方が良いということです。なぜなら高レベルのテストで逃げられるほど高レベルであるほど、システムについてのその不変条件は真実のままでいて、より低いレベルで柔軟性があるからです。
コードモジュールのすべての単一関数に対して千のユニットテストがある場合、それを変更するつもりはありません。ただそれだけです。それは理解されていない方法であなたに寄りかかります。そして再び、これはテストが良いが、あまりにも多くは悪くなることがあり、これらのことについて本当に注意深くなければならないところです。
コストベネフィット分析に戻ります。テストが良いことができる唯一の理由は、コストよりも利益をもたらす場合です。生産で現れたバグを少なくして、見つけるのが困難だったり、何らかの破滅的なことが起こるのを防いだり、開発中にバグが少ないので開発を速くしたりします。
何であれ、あまりにも遠くに行くと、テストのコストが見つけているバグのコストを上回り始めます。その点に達した時、今度は悪いエンジニアリングをしているだけです。テストのせいでプロジェクトがより多くのコストがかかるようにすることは、実際に最終的により信頼性の高いソフトウェアを生産しない場合、プラスではありません。
だからそのコストベネフィットトレードオフを正しく設定していることを確認する必要があります。プログラマー時間はゼロサムだと言う方法です。テストを書くのに費やす時間は、コードを書くのに費やす時間ではありません。そのコストベネフィットトレードオフが間違っている場合、実際にプロジェクトを助けるのではなく、傷つけています。
だから通常のコードと同じように、テストをどこに置くか、どのように書くかについて知的でなければなりません。何があなたの時間を取るべきで、何がそうでないべきかについて良い感覚を持たなければなりません。
完全に公平に言うと、CrowdStrikeは本当にすべてのものをテストしました。彼らはたくさんのテストを持っていました。多くの多くのテストを持っていましたが、世界を一週間ほどオフにすることができました。それは実際のことでした。
だから、すべてのテストが価値あるわけではありません。そして私たちがテストについてのエピソードを持った時にあなたが言及したと思いますが、Prime、非常に少数の人々に出荷して、段階的ロールアウトとして非常に注意深くするということです。
CrowdStrikeがなぜそれをするのかというと、「これらのことをより遅くロールアウトできるほど（彼らの場合、ゼロデイのものに先んじようとしているので、より遅くできるとは感じられなかったのだと思いますが）、早期にカナリアを取得して、100%のユーザーの生活を台無しにしない方が簡単です」。
そしてテストについて覚えておくべき本当に良いことは、テストは知られているバグをキャッチするということです。知らないことについては包括的なブランケットではありません。
考えるにはあまりにも微妙なもの、テストでチェックすることを考えなかったものは、そのテストでキャッチできないかもしれません。なぜならそれをチェックすることを考えなかったからです。
まさに。彼らは発見されたもののためにテストするだけです。まだ理解していない多くのものが潜んでいます。
さて、Carson、あなたはミームマスターとして知られています。実際、あなたのミームがTwitterでそれほどヒットしなかった時はいつでも、私たちの共通の友人にイエスからの引用をささやくと聞いています。イエスかもしれませんが、ソロモンかもしれません。
しかし、あなたは豚の前に真珠を投げないと言います。なぜなら彼らはミームを理解せず、ミームが十分良くなかったからです。それであなたはミームマスターです。
まあ、私はそれに同意しません。でも私はミームを作ります。私について嘘をつかないでください。私たちはすでにこれについて話しました。あなたは冗談を言おうとする時だけ超真面目になると言いました。超真面目になって、この冗談を作る時です。
それらを機密で送ったんだ、Brian。私が相互かもしれません。でも、あなたはCarsonをよく知っているべきでした。彼は文字通りリーク狂として知られています。
Carsonをよく知っているべきでした。これはチェスの40手かもしれません、TJ。Grug Brainの本を売ろうとしているだけです、man。それが私がここでやっていることのすべてです。
ここでの取引は、TJ。あなたは最新版を持っていないのですか、TJ？あなたは持っていないだろうと思いました。大したことではありません。これの更新されたバージョンがあります。ソフトカバーがあって、私は甘いカバーを手に入れました。このピクセルアートのようなものです。
みんなHypermedia.systemsを買って、それからtobrain.devに行って、そこでも本を買ってください。
この本は何ですか？実際にちょっとクイックにやってみましょう。Carson、この本について教えてください。今興味があります。知りませんでした。
Hypermedia Systemで、hypermedia.systemsに行って無料でオンラインで読むことができます。それからハードカバーとソフトカバーがあります。それらは異なるカバーです。ハードカバーは現在はUS Graphicsによって作られました。当時はBerkeley Graphicsでした。最高のフォントを作ります。最高のフォントです。Berkeley Mono。Berkeley Monoを称賛します。Berkeley Monoは本当に良いです。
それからソフトカバーPrime。それを持ち上げてください。それも本当に良いです。あなたはそれを持っていますか？ええ、そうです。私は持っています。今鏡写しになっていますが、それはぼやけています。手動で調整しなければなりません。でもそれはかなりクールです。
とにかく、それは基本的にHTMXについての本です。3つのセクションがあります。そしてそれは基本的に、HTMXはハイパーメディア指向なので、最初のセクションは「ねえ、子供たち、ウェブが実際にどのように動作するかはここにあります」のようなものです。
ハイパーメディアが実際にどのように動作したかはここにあります。ウェブ1.0スタイルアプリのようなもので、私たちはそれを構築して、それから中央の章は「よし、私たちはそれをやった。HTMXでそれを良くしよう。同じアイデアに基づいて、ハイパーメディアの基礎的なもの、ウェブの基礎的なもの、私が言うところの上でHTMXで段階的にそれを改善しよう」のようなものです。
それから最後のセクションはHyperviewと呼ばれるモバイルハイパーメディアについてです。これはAdam Stinskyという男で、私が親しい友人で、彼は基本的にモバイルハイパーメディアシステムを構築しました。
そしてそれは「ハイパーメディアはウェブだけについてではない。ここに、Hyperviewの良いところはアプリストアでモバイルアプリを更新してユーザーにアップデートを送る必要がないということを示すクールなものがある」のようなものです。
それはウェブが行うのと同じデプロイメントモデルを一種に活用します。そして誰がこの本の最適なターゲットオーディエンスだと言うでしょうか？
私は若いウェブ開発者のために書いたと思います。でも正直に言って、年上の人たちの多くもそれが好きです。なぜなら「ああ、これを覚えている。これはクールだ」となるからです。
でもそれは過去10年で成人した若い開発者のために書かれました。「ここにReactがあって、ReactとJSON APIがすべてで、それがあなたが慣れているもの」のような時です。だからウェブがどのように設計されたか、ハイパーメディアとは何か、ハイパーメディアの特別なところは何かのような背景を持っていません。
なぜウェブが分散システムとして他の分散システムに対して成長するのに非常に効果的だったのか？そしてその多くは、ウェブの統一インターフェースと呼ばれるものに要約されます。そして本を読むか、それについてのエッセイもいくつかあります。
私がHTMXについて初めて話し始めた時の1年半前くらいに私はそれを読みました。それは素晴らしいと思いました。ウェブで持っているたくさんの異なるオプションについて考えるのは非常に興味深く、私がいつもJavaScriptを書きたくなかった時にクールでした。
だからHTMXを異なるバックエンド言語で使うことを探るのは楽しく、ページ全体をリロードしたくない時はいつでもひどいUXで、ブラウザがそのツールを別々に人々に与える方法を見つけていないのは悲しいと思います。
さて、ミームマスターとして、私がそれを言った理由は、Caseyが少しトラブルに遭ったと信じているからです。
私はこれについてあなた方と話したかったのですが、Carsonがいるとは知らず、彼がミームマスターだとも知りませんでした。だから今日やることが特に適切であることがわかります。
しかし、少なくともPrimeやTeのようなあなた方は、すでに知っていました。つまり、ソーシャルメディアにいて、群衆をミームに関与させる方法を知っています。
Facebook.comでたくさんのいいねを取得します。まさに。つまり、あなたはfacebook.com、MySpace、これらの上昇しているプラットフォームのすべてに載っています。5人以上の友達よりもずっと多くです。
だから個人的な経験について話すのに良い時だと感じました。それが鳥のセックス鳥のセックススパイラルだと言ってください。
悲しいことに、そうであったらいいのですが。そうであったらいいのですが。でも残念ながら、そうではありませんでした。そして私はあなたにソートのように心を戻してもらいたいのです。
ウェブが一種の上昇していた時代に、ファングがあったことに注意してください。FANGの略語にはMがありませんでした。Microsoftはその略語にありませんでした。Microsoftはホットネスではありませんでした。ウェブが引き継いでいました。
彼らはもうそれほど関連性がない古いプレーヤーのようなものと考えられていました。何であれ、私はWindowsを使ってブラウザを起動するだけです。だから大学から出てくるすべての新しい新兵、採用しようとしている夏のインターンたちは、みんなGoogle、Amazon、Appleに行っていて、Microsoftには行っていませんでした。
昔、これはたぶん5、6年前だと思いますが、おそらくこの状況によって推進された未知の理由で、彼らのリクルーターの一人がこのメモを送り、私は今Twitterにそれを投稿しています。約束通り、Prime。
あなたがそれをスクリーンに載せることを期待していました。このために瞬間のために、あなたをフルスクリーンにしました。いいえ、いいえ、いいえ、いいえ。これはみんなのために出て行くつもりです。あなたはこれができます、Prime。実際、あなたのTwitterアカウントは何ですか？
CMuratori、C M U R A T O Rです。そして私はこれが言ったことをあなたに読みます。これはこれは彼らのリクルーターの一人がすべてのインターンに送ったメールです。そして「Hey, bae intern」と言っています。B AEです。
それが電子メールの開始です。それは小さな睾丸付きのパーティハットを持っています。そのemojiが何であるべきかわかりません。小さい記号の後に3のようなものです。ああ、それはハート記号です。睾丸ではありません。
つまり、私がそれを見る時、パーティハットをかぶった睾丸が見えますが、まあ。それはハートです。Hey, bae intern、そうです。それが彼女が開いたものです。Kimが実際に男性の名前であることを知っているので、彼または彼女と言います。だから、リクルーターが誰だったかを正確には知りません。
「私はKimです、Microsoft大学のリクルーターです。私のクルーは、7-Elevenでインターナ・パルーザであなたとベイエリアのインターンの群衆と一緒にぶらぶらするために、シアトルの私たちの本社から降りてきています。でもより重要なことに」緑のアンダーラインテキストで「Sick。私たちはイベントの夜にサンフランシスコのオフィスで独占的なパーティーを投げていて、あなたは招待されています」。
そしてここにお金の部分があります。「hella noms、たくさんの飲み物、dr ks、最高のビート、そして昨年と同じように、私たちはyammer beer pongテーブルを取り出しています」。
終わりの行は何らかの理由でオレンジ色のすべて大文字です。下にスクロールしてください。「月曜日の夜にlitになることにHell yes」。
分かりますか？アイデアがわかりましたか？このパーティーを投げましょう、dude。このパーティーを投げましょう。私たちはサンフランシスコでこのパーティーをするべきだと思うだけでなく、でも、スタンドアップエピソード5を知っています。
私たちはこれをするべきだと思いますが、その上に、科学者が緑のバイアルを持ち上げているそのミームを知っています。「純粋なcringeを蒸留した」と言っているだけです。これが私が現在経験していることです。
これがBill Gatesから直接来たとは思わない人々がチャットにいます。それは私にとって信じられないほど失望です。Bill Gatesがこれを書かなかったと思うなら、あなたは気が狂っています。
彼はもうそこにいませんでした。ここに行きます。Shadow bear。この男に聞いてください。これはBill Gatesです。これは古典的なBill Gatesです。
引用符で囲まれた「Kim」ですが、私たち全員それがBill Gatesだと知っています。Bill G secretlyです。このメールのメタデータはどこですか？最終的にBill Gの「から」はありますか？情報公開法の状況が必要です。
別々にミームの前に？はい。サンフランシスコでこのパーティーを投げて、developers, developers, developers, developersのライブエピソードをするべきです。
私の最近のものを見ましたか？私はそれを再演しました。Carson、見ましたか？真面目ですか？見ませんでした。すみません。彼はこれについて非常に深く行きました。最後にそれを再生します。
再生しましょう。ええ、ええ。お願いします。それを見たいです。一度に一つのミームです。一度に一つのミーム。まさに。Smart。Smart。
それで、何が起こったかをただ話し、私が言いたいのは、みんなになぜ私がこのミームを台無しにしたかを説明してもらいたいということです。これは簡単にできるはずだと感じました。
それは美しいです。これはとても良いです。私はTwitterにこれを投稿しました。誰も気にしませんでした。これはミームになるべきです。「月曜日の夜にlitになることにHell yes」はミームになるべきです。それがミームにならない方法はありません。
だから私がしたこと、そしてこれは明らかにAI画像生成の時代の前です。だから、画像編集パッケージをロードして、当時のCEOであるSatya Nadellaの写真を見つけに行きます。
だから彼はこの時点ですでに引き継いでいます。Steve Balmerではありません。彼はもう行っています。だから私はJack Johnson。すみません、続けてください。
分かりました。すみません。別のミーム。さて、Satya Nadellaの講演をしている写真を見つけます。CEOとしてのプレゼンテーションの一つを与えているような写真で、手がすでに本当に大きなウォーターボングを持っているような位置にある写真を探します。
手を少し動かさなければならないとわかっていますが、彼が何か本当に大きなものを持っていて、月曜日の夜に本当にlitになっているようなものにかなり近いものが欲しいのです。少しほろ酔いになるのではなく、完全に行くような。
私はそれをします。この私は最もクレイジーなウォーターボングを見つけます。正しく彼の口に行くように回転して配置されているものを。
私はそれら二つをPhotoshopで合成します。ライティングさえ合成します。コンピューターグラフィックスで働いているので、ライティングを合成します。シャドウイングを正しく取得しようとします。この大きな古い煙の雲を取得します。ステージ上でこのものを激しく吸っているだけのように、それを覆っています。
私は「これまでで最高のミームです。みんな気に入るでしょう」と思いました。
私はそれを投稿して、誰も気にしませんでした。そしてここにそれがあります。私はリプライに入れています。私は今それを引き出しています。どこに投稿しましたか？どのように最初にこのミームを送りましたか、Casey？どのように送りましたか？
わかりません。戻って見る必要があります。さて、持っています。本当に良いです。今そのミームを取るだけなら、1,000のいいねを取得すると思います。
それを盗んでください。盗んでください、man。今すぐそれを盗んでください。新しいツイートにコピーペーストしてください。
私はすでに投稿しました。すでに投稿しました。新しいツイートに。それを爆破してください、boys。
私もそれをやっています。それを爆破してください。少し料理しすぎたかもしれないと思います。私もそう思っていました。行きすぎたかなと思いました。
画像が良すぎます。ちなみに、そのJPEGをもう少しJPEGify する必要があります。それが実際の問題です。そんなに良い画像だと思います。
ちなみに、あなたは本当に、あなたはこれをbeer bongと呼びました。それはただの、ただの昔ながらのbongです。ウォーターボング。ウォーター。それはウォーターパイプです。ああ、すみません。Berkeley。Berkeleyに行きました。彼はこれについてすべて知っています。
私はいつもそれらをウォーターボングと呼ばれるのを聞いたことがありますが、わかりません。
これがあなたにとって巨大な巨大なミームになることができた方法があります。そして、Primeが誰これを投稿しているか誰も知らないので、まだ時間があります。
元の画像を取って、50%の不透明度で上に置くのです。「Hey Bay Interns, what’s up?」と言っている元のものです。
Hey Bay Internsはかなり良いです。彼らはBay Areaの出身だが、Bayのように綴られているので、それはとても良いと思います。
オーバーレイがある場合、それは100,000のいいねをやるつもりです。そうですか？でもそれは再撮影する価値があります。明日送り出してください。
アルゴリズムでそれをジュースします。このミームにラッチできるかどうか、いくつかの異なるアプローチを試してみます。後でこれを聞き返す人々が、スタンドでそれを聞く前にすでにミームを見ていることを期待しています。
それはクールでしょう。私は、これを投げ出したいと思います。このミームを個人的に見て、その品質がスタンドアローンではなく、リプライにあると言います。
そのメールがリークされて出回っていて、あなたがこれでそれに返信した場合、これがとても面白いので、元のものをレシオできると思います。
そしてこの一つのパワーはそれ自体よりもリプライにあると思います。クォートクォートツイートまたは何であれ、ワンツーがあるので、確実に非常に効果的です。
ミームは男を選ぶ、男はミームを選ばないと思います。時々それは起こり、時々起こりません。あなたは豚の前に真珠を投げてはいけないと言うだけです。それがあなたが言わなければならないすべてです。
それをして、とても多くのフラットになったことがあります。ビューをたくさん取得しなかった場合、誰もそれらを削除して、起こらなかったふりをしてください。それと一緒にいて、クリンジーになることに慣れてください。
それも真実です。クリンジを抱擁してください。バスローブを着ているので、何をするつもりですか？Casey、あなたは二つ持っていると言いましたか、それとも一つだけでしたか？
一つだけです。それだけでした。本当にミームを作ろうと感じた唯一の時で、それから何も得られませんでした。10のいいねを取得するミームに何時間も費やして、それから誰かに愚かなことを返信するだけで1,000のいいねを取得します。
そのようなものに注意を払うことはできません。撮影し続けなければなりません。撮影し続けなければなりません。しかし、ミームに費やす10分ごとに、品質が下がると言えることもあります。
なぜなら最初にミームを見て面白いと思った理由は、あなたの中で何かが回転して「ああ、それは面白い」となったからです。
そしてTwitterでは、誰かがそれを好きになったり嫌いになったりするのにそれくらいの時間しかありません。だから私は事前にツイートするつもりのことについて考えません。スケジュールされたツイートは0です。ツイートをスケジュールしたことはありません。それが起こった瞬間、私は「それが時です」となります。
公平に言うと、Prime、私たちは多くの時間を費やしてヨットを借りてミュージックビデオを作りました。
だからそれは異なります。それは異なるメディアです。それはYouTubeです。それはYouTube動画です。それはミームですが、異なる種類のミームです。異なる種類の消費可能なミームです。
だからTwitterに関しては、私は本当にそれが多くを決定すると信じています。最高のミームはあなたの心またはTwitchチャットから来ると信じています。
彼らはあなたの脳からは来ません。メディアはミームです、とMarshall McLuhanは言います。メディアはメッセージを知らせます。多くのことにも当てはまります。あなたのツイートがおそらく何についても誰の心も変えないでしょう。
だから聴衆に合わせて楽しんでください。実生活のアドバイス。すみません、忘れました。TJ、それは本当に良いアドバイスで、それがここで受け入れられるかどうかわかりません。
スタンドアップの奥深くにいるので、大丈夫です。Prime、私がチャットで送ったもので1分20秒から再生してください。Casey とCarsonが私のオーディオを聞けるようになるのが最高でしょう。
私は映画のオーディオを心で知っています。でも私のオーディオを聞けることが非常に重要です。
誰が座れと言ったのですか？それが私のお気に入りの部分です。あなたはその部分をやりましたか？私はその部分をやりませんでした。ああ、TJ。すみません、すみません。
彼は聴衆の誰かが座ったことに非常に怒っています。私たちはやっていますか？彼の退職のものを見ましたか？Prime。この中の1分20秒です。
1分20秒はまだSteve Jobsにいます。Steve Jobsのものを見て、それから移行してほしいのです。問題は、Riversideで彼らが聞くためのオーディオを取得できないことです。
ただここに。いいえ、私たちはただTwitterに投稿して、私はそれをクリックしに行きます。チャットにあります。チャットにあります。チャットで見ることができます。
私はジャンプアウトして、スクリーンで再生して、人々はそれを聞くことができます。あなたはそれを聞くことはできません。12でCaseyのカウントダウンを与えてください。
何のチャット？ない、チャットにありません。Twitchチャット、敗者。Twitch、私は48です。Twitchチャットを持っていません。誰もそれが何を意味するか知りません。
私はスタジオで送りました。誤って30秒ほどTwitchでストリームしたことがあります。そこに行きます。「誤ってTwitchでストリーム」と言いました。
あなたはいつもそれをやっています。OBS。Twitchでサインインして、ストリーミング開始を押しました。何が起こったかわかりません。
私はまだPrimeがいくつかのミーティングをリークすることを心配しています。一日中ストリームを残すつもりのようです。先週それが起こりました。幸運にも、Twitchチャットが私のチャットでメッセージを送って、サイドのものに開いていたのを見て、「Yo、Primeはまだライブです。あなたのミーティングを聞くことができます」と彼らが言っているのを見ました。
それはない、それは悪い状況です。それは悪い状況です。さて、みんな静かにしてください。3、2、1で始めます。
私はより多くの情報のために私たちのCTO、Steve Balmerに渡すつもりです。CTO。やってください、Steve。
誰かがそれをリークしているのか、私だけですか？エコーがあります。あなたのマイクをミュートして、TJ。
私でしたか？私があなたを聞いていたのかもしれません。もう一度やってください。もう一度やってください。
聖なる牛。タフになる必要があります。ここで行きます。現場の64,000ドルの質問は何ですか？最も聞かれる質問は何ですか？
曲がりが好きです。曲がりが好きです。コーヒーについて何をするつもりか、Steve？それは非常に良い質問で、非常に非常に明確な答えがあります。
開発者、開発者、開発者、開発者、開発者、開発者、開発者、開発者、開発者。
これは本当によくできています。そうです、そうです。ああ、いいえ。いいえ。
ああ、神よ、DFC8を取得しました。知っているべきでした。Primeをよく知っているべきでした。
ここで、あなたはまだ「誰が座れと言った」をやる機会があります。なぜならそれは彼がステージに走り出す開発者のものとは異なるものだからです。だから「誰が座れと言った」「立ち上がれ」の第二のSteve Balmerがあり得ます。
別のものをリリースしようとします。みんな。実際に私はそのシャツに水をぶちまけて、すべてをやりました。しばらく本当に激しく乗った後にもそれをやりました。
でもシャツがただ透明になっているだけでした。暗い青に変わりませんでした。だから本当にうまくいかず、私が望んでいた外観ではありませんでした。つまり、私が何を意味するか知っているなら、それ以上のものを見せていました。
だから少し乾いたが、試しました。そこに水をかけました。ただ私たちが求めていた外観ではありませんでした。
間違った種類の素材でした。かなり良いミームでした。彼の動きのかなり良いコピーでした。曲がり、非常にそのような原始的なスタンスを持っています。
私は冗談ではありません。それをやる前に少なくとも30回連続で真剣に見ました。全体を通して全部を取得するために。私は専念していました。
これは非常に非常に良い仕事です。クリンジが良いという別の証拠です。言葉がないために。Andy Turtleのようなものです。良いです、man。
誰も、1000年後、誰もあなたの超ヒップな投稿を覚えていないでしょうが、Balmerを再生しているでしょう。
そうです、dude。Steve Balmerの模倣者として不滅化されることができるなら、それはとても病気です。すべての終わりの終わりになるでしょう。
それをやることができるためにストリーミングを始めたと思います。
クリンジーであることについて忘れている一つのことは、それを受け入れるだけなら、それはどういうわけかより少なくより少なくクリンジーになることです。
なぜなら他の人にクリンジをもたらすことができるなら、つまりそれはThe Officeの全ショーはただMichael Scottに信じられないほど激しくクリンジするだけです。見るのがとても痛いエピソードがいくつかあるか、最近見ていたのは何でしたか？NetflixのI think it’s time for you to leaveだと思います。
あなたがただそこに座って、私は非常に深く不快に感じているような時間全体です。そしてそれはただこの素晴らしいクリンジが素晴らしいからです。
まあ、連帯があると思います。私たちクリンジのような。私たちクリンジなタイプは連帯を持たなければなりません。Chestertonからの引用があります。「人間のコメディは人間の悲劇を生き残る」のようなものです。
そしてそれはただ、どれほどクリンジな人でも、そこに人間がいて、それはすべて良いのです。私たちはみんなそれを理解しようとしています。誰かがただ猿になるとき、本当に面白くなることがあります。「dude、ええ、man、それはかなり面白い」となり、私は多くのそのような態度を感じます。
「ただ別の人がそれを理解しようとしている。すべて良い」のようなクリンジの態度は良いことです。
それが終わりです。それが完璧です。それがクローザーです。またね、みんな。スタンドアップの次のエピソードで会いましょう。
今週私にブロッカーはありません。ハイパーメディアシステムをチェックしてください。Grugブレイン。本を買ってください。
クリーンコードに対しては無関心です。でも彼が言うことを知るためにまだそれを読んでください。すべてに同意しなくても、まだ良い読み物です。
ありがとう、Uncle Bob。それから彼は言及しました。私が「あまりにも思想的」と言ったからです。そして彼は「開始時に、私はこれが私がすることの方法だと言う」と言いました。
そして彼に公平に言うと、私は序文を読んだことがありませんでした。なぜなら序文を読まないからです。でも彼は序文で「ねえ、これは私がコードする方法です」と言います。そして「それに反対する他の人々がいる」のようなことを言います。
前書きを読みますか？私は動機のある質問によって読む傾向があります。前書きを読むことができます。つまり、以前にやったことがあります。パーセンテージを与えることはできませんが、前書きを読んだことがあります。
Uncle Bobの新しい本We Programmersを購入するなら、そこに投げ込んだ私の前書きを読むことができます。
投げ込んだように、YouTubeコメントのように投げた。彼は本当にそれを書いて、それは良いです。私は両方を読みました。それは良いです。
Carson、今日参加してくれてありがとうございました。素晴らしかったです。そして絶対にあなたの本を確認します。
スタンドアップでのUncle Bobがインターネットを壊すでしょう。ある時点で起こるかもしれません。私とUncle Bobをここに呼んでください。行きましょう。
その一つは座ります。あなた方は私のスライドを持つことができます。
さて、スタンドアップの一部になってくれたみんな、ありがとう。スタンドアップエピソード7。ねえ、この時点でまだ周りにいるなら、十分に愚かなことを言ってほしいです。
Boot up。私のスクリーンに5つの有効なエラー。