The following post is an excerpt from Chapter 8 of by Piotr Sarna and Cynthia Dunlop. The book explores seven popular engineering blog post patterns: Writing for Developers: Blogs That Get Read 開発者向けブログ Writing for Developers: Blogs That Get Read 開発者向けブログ 『BUG HUNT』 Xで書き直す How We Built It レッスン学習 トレンドに関する考え方 非市場製品展望 ベンチマークとテスト結果 ♪ 「Bug Hunt」のブログ投稿パターンは、プログラミングの世界の探偵ストーリーに等しいものであり、テーマ、主なスピリット、サイドスピリット、主人公(あなた)、敵対者(通常はあなたも、最初に2週間前にバグを導入しました)。 8.1 目的 バグ狩りの記事を書くことは、狩りの成功に依存して、最終的にミスが落ちた場所、およびいくつかの他の要因に依存して、いくつかの目的を果たします。 8.1 知識の廃棄 バグが現れ、修正されたという事実は間違いなく重要ですが、さらに重要なことは、それが再び起こる可能性を減らすことです - そして、それが起こった場合に何をすべきかを知ることです。 いくつかの死の終わり 非常に説得力のある赤いハーリング 最初は役に立ったように見えたツールですが、結局無関係でした。 非常に役に立つことが証明されたもう一つのツール 2014年からのいくつかのブログ記事があなたを根源の原因を発見させた これらのすべてのステップは、他の類似の問題の将来のデバッガーにとって非常に役に立ちます(おそらくあなたは2週間も年上です)。過去の死の終わりや迷惑の意識は、ここで特に役に立ちます。既知の赤いハーリングの迅速な識別は、将来のデバッガー(あなた)に数時間の非生産的な研究を節約することができます。あなたはバグ狩りのブログ投稿を古代の知識(2週間またはそれ以上)のスロールとして扱うことができます。 8.1.2 グローバルバグ認識 確かに、あなたが修正したバグは、あなたのプロジェクトにユニークに適用されていません。代わりに、それはあなたの選択した言語、図書館の1つ、または特定のハードウェアの迷惑な落とし穴によって引き起こされました。あなたの記事は、ほかの人々が「Huh、我々はまったく同じセットアップを持っています - 私を疑問に思います ..." それはまた、そのテクノロジーの背後にあるチームを動機づけ、他の人々が同じミスを犯すのを止める方法を考える可能性があります。 その結果、あなたが興味深いバグを修正した方法についてのストーリーを書くことは、同じカテゴリのいくつかの他のバグが世界中で修正される可能性があります。 Bloeding Edge ソフトウェア 新しいハードウェア 若いオープンソースコミュニティ これらのプロジェクトはダイナミックに発展する傾向があり、業界標準に比べてテストカバーが非常に少ないのは、プロジェクトの重要な量で実装するにはあまりにも若すぎるためです。 8.1 ブレイク テクノロジーの世界の誇り - 適切な量 - あなたとあなたの仲間のために良いです。 何か興味深いことをすることを誇り、狩りとバグを解決するように、あなたとあなたの読者に役立ちます: It's educational. Your audience can presumably learn something by reading how you achieved your goal. It broadens your professional network. People intrigued by similar technologies and challenges will likely reach out to you as we outlined in Chapter 1. It feels good. There’s no shame in acknowledging that attention is one of the benefits of telling the world that you did something. It yields free criticism – hopefully constructive criticism, but valuable either way. The (often illusory) sense of anonymity on the Internet makes it easy to criticize others, so you can count on lots of comments and nitpicks after your article goes public. But after filtering out the vitriol, you can often learn something new, or even revisit your whole approach to the problem. 8.2 観客 バグハンティングは技術的なトピックであり、バグハンティングのブログ記事の視聴者は本質的に技術的である。 類似の背景を持つ人々(つまり、彼らはシステムに類似のバグを導入したり、それに苦しむ可能性があることを意味します) 生産バグを見つけて修正する仕事をしている人々 似たようなバグ狩りの真ん中にいる人々 このクラスのバグが再発するのを防ぐことができる人々(バグが発生したテクノロジーの背後にある人々、または故障防止ツールを開発している人々) 探偵フィクションファン あなたの同僚たち 未求のアドバイスに特化したプロのインターネット批評家 観客が誰かであると仮定することは安全です: すでに記事で使用する技術的な用語や言語を理解するのに十分な専門的背景を持っている もしそうでなければ、彼らを見上げ、学ぶ用意がある。 そうでない場合は、彼らがそれを理解しているふりをすることは絶対に大丈夫です。 したがって、バグハンティングのブログ記事を「中間レベル」(またはそれ以上)の読者に宛てたものとして扱うのは大丈夫で、「新人」ではなく「先進的なテクニカル用語」は大丈夫です。 8.3 例 バグはどこにでも起こりうるので、バグ狩りブログの投稿もできます。野生では、ビッグテク、ユニコーン、スタートアップ、および個人ブログのさまざまなブログに掲載されたバグ狩り投稿を見つけることができます。一般的に、大手ハイプロフィール企業によって掲載されたバグ狩り投稿は、オープンソースの貢献や週末のプロジェクトについて書く個々の貢献者よりも、驚くほど少なく一般的です(そしてより保護されています)。 Here are some prime examples of blog posts that apply the “Bug Hunt” pattern, along with Piotr’s commentary on each. 8.3.1 NUMA パフォーマンスバグの狩り マイケル・チョイノフスキー Author: ScyllaDB Blog ( ) Source: https://www.scylladb.com/2021/09/28/hunting-a-numa-performance-bug/ Summary この記事では、NUMA(非均一メモリアクセス)設計を用いた現代のハードウェアで起こるパフォーマンスの回帰を説明しています。この回帰は、実行の半分でランダムに発生するように見え、それを特定するのがはるかに難しくなりました。この記事では、問題を診断するためのいくつかの失敗した(しかしそれでも熟練で印象的な)試みを共有しています。その後、観察の1つは、突破と驚くほど小さな修正に直結します - コードの行で測定されます。 Commentary これはバグ狩りのブログ投稿の頂点です. それは深く技術的ですが、同時に従うのは簡単です. 未経験の読者は、ニッティーグリッティな詳細の一部を省略し、まだ多くのことを学ぶことができます. 問題を診断する失敗したすべての試みは教育的であり、将来のデバッグで確実に役立つ。 執行可能なバイナリを直接編集する際に著者が示す偶然の専門知識は、テキストファイルであるかのようにブログ投稿を非常に楽しい読み方にします。この問題の解決策は、特にプログラマーの心にとって非常に満足しています: 見た目で無邪気なコードの一行だけが変更され、すべてのパフォーマンス回帰が排除されます。 8.3.2 なぜ私のリストはそんなに遅いのですか? アモス・ウェンガー Author: トップ > ブログ > ( Source: https://fasterthanli.me/articles/why-is-my-rust-build-so-slow) Summary この広範なブログ記事は、Rustプロジェクトのコンパイラタイムの問題を調査しています. それは、コンパイラ自体をプロフィールする方法のための複数のテクニックを示し、コンパイラプロセスを管理可能なパーツに分解し、各パーツがどのくらい時間がかかるかを測定します. それは、あなたのRustビルドタイムに満足していない場合、すべての幅広いテクニックを適用するための正直なアドバイスです。 Commentary 平均的な技術的なブログ投稿に比べると、これは純粋にポジティブな意味で、ハグです! 熟練した読者はそれを読み取るのに30分ほどかかることができ、それは恐らく三つまたは四つに分けて消化し、スクリーンから休憩を取って、頭の痛みやディロピアを避けるのに良いアイデアです。 多くのテクノロジー記事は、読書の4〜6分にできるだけ多くの情報を圧迫しようとしています。そしてそれは、時々漫画の休憩で一日中屋外で遊ぶのではなく、スマートフォンで育てられた人間の平均的な注意の範囲を考慮して、公平です。 この記事には、著者のアルターエゴ、クール・ベア(Cool Bear)が、定期的に短いユーモアなコメントを追加する独特のスタイルがあり、読者は(長い)読書プロセスを通じて関わっています。 ♪ このタイプのバグ狩りブログ投稿はまた、Rustコンパイラのデバッグのためのテクニックの百科事典として役立ちます. I have it bookmarked, just in case I ever need to refresh my knowledge of how to measure linking times in my projects. The conclusion is also quite unconventional: instead of building tension and finally presenting readers with a surprise solution, it's simply an honest summary with encouragement to reach out. 私のプロジェクトでリンク時間を測定する方法についての知識を更新する必要がある場合に、私はそれをブックマークしました。 8.3.3 コードの単一行が 24 コアのサーバーをラップトップよりも遅くした方法 ピョートル・コラツコフスキー Author: ウィリアム・クロスキーのブログ( ) Source: https://pkolaczk.github.io/server-slower-than-a-laptop/ Summary このブログ記事は、多くのCPUコアを持つマシンで、地元のベンチマークがどのようにボトルネックを検出したかを説明しています。著者はパフォーマンス分析を共有し、いくつかのプロファイリングを実行し、その後、近代的なCPUがキャッドの下でどのように動作するか、およびプロセッサのキャッシュがメモリをどのように管理するかについていくつかの説明を提供します。 Commentary This is another stellar example of a bug hunting blog post. Its title is a little clickbaity, but still elegant enough to avoid being rejected by the average ad-blocking software. The technical details are much more universally understood than the ones in Chojnowski’s NUMA blog post (described earlier in this section). The article is sneakily educational, digressing on things like "How many nanoseconds does L3 cache access take on average on Intel Xeon." That's great practice; it leaves those details imprinted in readers' minds without them realizing it. Who knows – maybe one day that tucked-away tip might help fix a performance bug in another project. Overall, the article leaves readers satisfied with the result, and also a tiny bit smarter in the field of CPU architecture and performance. 8.3.4 Tricky Direct Memory Leakのデバッグからのレッスン サンチャイ・ジャヴェリア Author: Pinterest Engineering Blog ( ) Source: https://medium.com/pinterest-engineering/lessons-from-debugging-a-tricky-direct-memory-leak-f638c722d9f2 Summary Pinterestの開発チームは、分散型システムの故障を引き起こしたストリーム処理コードメモリ漏洩を追い求める経験を共有し、Java環境のデバッグ技術を超え、最終的にメモリ漏洩を引き起こしたアプリケーションコードのバグを特定します。 Commentary This is a classic bug hunting article – so much so that it could be used as a blog post template for hunting down almost any issue in Java code. It contains the customary investigation steps, along with screenshots from observability tools. Also following custom, the culmination paragraph is called "The Fix." It explains that the culprit was yet another memory leak issue caused indirectly by garbage collection mechanisms in Java. Hint: It always is! この文脈では、結論は本当に地球破壊的な突破口ではありませんが、間違いなく読者の期待を満たしています。私は、ほとんどの読者が「ああ、私は最初から知っていた」と、根本原因を学んだ直後に考えます。 8.3.5 ZFS Is Mysteriously Eating My CPU (ZFSは謎に私のCPUを食べている) Brendan Gregg Author: ブランデン・グレッグ(英語版) ) Source: https://www.brendangregg.com/blog/2021-09-06/zfs-is-mysteriously-eating-my-cpu.html Summary このブログ記事は、予想以上に高いCPU使用率の謎の原因を追い求める方法を説明しています. It shows how to narrow the candidates down to a single function call with analytics tools and concludes with a surprising performance bug in ZFS – a file system implementation. ファイルシステムの実装で驚くべきパフォーマンスバグが発生しました。 Commentary タイトル自体は魅力的ですが、URLの何かがあなたに浮かび上がります:それはフラームグラフの発明者であるブレンダン・グレッグによってです! これは、個人的なブランドがとても重要である理由の素晴らしい例です。 「ブレンダン・グレッグ」を見ると、私はすぐに記事が興味深いと仮定します ...そして私は最小限の間違いではありませんでした。 グレッグの専門知識を考慮すると、問題の分析は自然に炎のグラフを含んでいます。 根源的な原因はかなり驚きであり、グレッグは非常に非公式で面白い方法でそれを説明しました。 ブログ投稿も非常に簡潔です: 3 分間の読書、あなたが炎のグラフのスクリーンショットを見るために少し時間を預けても。 それはあなたが多くの知識、ヒント、興味深い技術的な詳細を圧縮するために何千もの言葉を書く必要がないことを明確に示しています。 More recent “Bug Hunt” blog posts on writethat.blog 「Bug Hunt」のブログ記事をもっと見る on writethat.blog トップページ > ブログ 8.4 特徴 バグハントのブログ投稿は、実際のバグハンティングと同じくらい変動しますが、以下の特徴を共有する傾向があります。 They recount the story chronologically, from the moment the evil bug manifested itself, to when it was pronounced dead 彼らは主に狩りの興奮(そして痛み)に焦点を当てている。 彼らは狩中に収集された証拠を自由に共有し、読者は探偵の帽子を着て一緒に遊ぶことができます。 彼らは主に、議論されているテクノロジーを知っている経験豊富な開発者に向けられています(または彼らが進むにつれて学ぶ準備ができています) 彼らは今、興味深いかもしれない技術的なニッグを提供し、後で命を救う それぞれの順番を調べてみましょう。 8.1 クロノロジー バグ狩りブログの投稿は、探偵ストーリーの技術的同等のものであるため、しばしば特定の構造に従います(探偵ストーリーの構造についての紹介またはリフレッシュしたい場合は、生成型AIはここで適切な仕事をします)。 問題が定義されると、狩りは、通常、いくつかの失敗した(しかし教育的)試みから始まります。緊張は、著者が彼らの aha 瞬間に到達するまで構築され、その後、修正説明(そしてそのセクションは通常「The Fix」と題されます)。 8.4.2 ハンターで重い 調査プロセスを説明する投稿の約80%を費やすことは良い指のルールです. たとえば、ここでは、上記の例のブログ投稿のそれぞれが調査にどれくらいの時間を費やしたか(単語数に基づいて): 85% hunt Chojnowski: 83% hunt Wenger: 83% hunt Kołaczkowski: 82% hunt Javeria: 93% hunt Gregg: 8.3 どこにでもある証拠 バグハントのブログ記事は通常、法学的証拠でいっぱいです。読者は、炎のグラフ、数字、グラフ、スクリプト、コードサンプルを見たいです。これは彼らがあなたの探偵の靴に踏み込んで、大きな暴露の前に謎を解明しようとします。 たとえば、以下は、例のブログ投稿で示された証拠のいくつかです。 Chojnowski: Database monitoring graphs (writes per shard), network and disk performance graphs, CPU statistics, flame graphs and instruction-level breakdowns, the CPU's performance measuring monitoring unit (PMU) events, and a variety of attempted code fixes Wenger: Cargo build timings, a timeline of compilation units, CPU usage and concurrency graphs, debug information, flame graphs, tracing through Chromium and Perfetto, attempted code fixes, dependency graphs コラッツコフスキー:ベンチマークツールの設計、パスポート結果(彼の4コアのノートパソコンで対24コアのサーバー)、フラームグラフ Javeria:Out-of-memory error details, backpressure tests, and multiple forays into memory monitoring(メモリモニタリング) グレッグ: Flame グラフ (もちろん!), ZFS マウント 詳細, arcstats, and all the source code, via a GitHub link フラームグラフは、バグ狩りブログの投稿で特に一般的です. 彼らはあなたのデバッグおよびパフォーマンスプロフィールプロセスを視覚化するための素晴らしい方法を提供します. そして、彼らはインタラクティブです - ユーザーは興味深い部分にズームし、特定の正規表現に匹敵するイベントだけをフィルタリングすることができます. Flameグラフは、LinuxのプロフィールプロフィールやRustの貨物のフラームグラフコマンドなどの一般的なツールの出力から作成することができます. 8.4 専門家フレンドリー Bug hunting articles tend to be expert friendly. The author usually assumes that the audience is proficient (or at least familiar) with the technological stack used in the article. Code samples and scripts shared in the article are typically targeted to readers who are familiar with the programming languages used. These types of posts aren’t conducive to basic explanations of core language concepts; if the reader doesn’t “get it,” they might need to soldier through it or just move on. これは「We Rewrote It in X」などの他のブログ投稿パターンとは明らかに異なります(第9章で議論されています)。 8.4 教育 Blog posts following this pattern can be quite educational for developers beyond the impacted team. The meaty part, bug identification, is abundant in details about how to inspect similar issues. Even more importantly, these sections are abundant in reproducible details: ones that are likely to be useful for solving all kinds of similar problems that readers might face in the future. The blog post serves its purpose if it leaves the reader equipped with a few more tricks they can apply, just in case they ever encounter a similar bug at some point in their life. たとえば、以下は、読者が私たちの例のブログ記事のそれぞれから学ぶことができるものについての高いレベルの視点です。 The kinds of issues you might encounter with complex memory architecture (NUMA), especially with ARM processors Chojnowski: Ways to improve your Rust build times Wenger: How modern CPUs work under the hood and how the processor caches manage memory Kołaczkowski: Java is evil Javeria: How to apply analysis tools like an absolute expert Gregg: 8.2 ドンツとドンツ 最高のブログ投稿は、最も拷問的なバグ狩りから生まれる。謎を解くという輝かしい感覚によって、鉄が熱い間、ストライキしてください。狩りの頂点が枯れる前にあなたの印象を書き、あなたの仲間が次のケースをより速く解決するのを助けます。 Here are some tips for writing your own Bug Hunt blog post. 8.5.1 誰かが(あなたのボス、あなたのボスの弁護士)あなたの透明性に悩まされるかどうかをチェックします。 これは、ユーザーに大きな影響を与えたバグを追いかけた場合、またはこのバグの公開があなたの会社の評判や/または重要な株式価格に悪影響を及ぼす可能性がある場合、特に重要です。 あなたがあなたの厳しく守られている企業の秘密のコードのスナップを公開する前に、あなたのボスと関心のあるすべての当事者がそれで大丈夫であることを確認してください. あなたがコードを飛び越えても、あなたの上司は依然として特定の情報を公表することを嫌がる可能性があります、特にバグがセキュリティに関連していた場合、または不幸なデータ漏洩で終わった。 8.5.2 Do a technical deep dive テクニカルな詳細は、いずれにせよ、必須です。 blog post. If your article lacks details like code samples, specs on the exact technology used, step-by-step instructions, etc., many readers will leave unsatisfied. Even worse, they might doubt your integrity. Perhaps the inconvenient bits were deliberately omitted to make the product look better? If you worry that you might be adding too many technical details, err on the side of more. Readers can always skip over them if they don't find them interesting. technical Bug hunting blog posts are especially expected to be loaded with tips, tricks, code, benchmark results, as well as links to open-source repositories and documentation. Otherwise, you rob readers of the fun opportunity to draw their own conclusions from the copious evidence. As noted earlier, it's fine to be expert-friendly here. You can assume that the audience is either already familiar with the technology described, or willing to catch up (with the help of your blog post). 8.5.3 すべての失敗について、残酷に正直であること あなたの失敗と不幸は、最初にあなたのブログ投稿に持って来たカタール効果を読者に提供します! 彼らはまた、バグ狩りの記事の最も教育的な側面を生み出します。 結局のところ、間違いから学ぶことは素晴らしいですが、最初に誰かの間違いから学ぶことはさらに良いです。 バグ狩りブログの投稿は、通常、根源の原因が特定され、バグが修正された後で書かれています。最初の段落で説明される痛みと苦しみがより多く、最終的な突破がより良いように見えます。類似の問題に苦しんでいる読者は、同様の問題の記述のためにインターネットを積極的に検索するので、「壊れた」、「故障」または「FUBAR」などの悲しいキーワードはすべて二重の目的を果たします - 彼らは著者の失望のための感情的な出入り口であり、さらに彼らはブログ投稿をオンラインで簡単に見つけることができます。 完璧で原始的なバグ狩りを伝えようとしないでください. 死んだ終わりと失敗した試みは多くの教育的価値をもたらします. プログラマー(もちろん、「偉大な頭脳」の同義語です)は同じように考えます. それは、いくつかの読者が同じ死んだ終わりに閉じ込められることを意味します - 彼らが最初にあなたの警告ストーリーを読まない限り。 8.5.4 Include numbers, benchmarks, metrics, and flame graphs Benchmark results, metrics, and all kinds of numbers are the equivalent of clues and proofs from the detective fiction world. Bug hunting blog posts look less legit if they use vague phrasing like "our system is now much faster." Readers will immediately think "Yeah, but how much faster?" followed by "Dear author, if you were 結果に誇りを持って、あなたはそれらを投稿したでしょう ..." あなたのメトリクスのスクリーンショット(またはそれ以上に、炎のグラフのようなインタラクティブな数字)は、読者の目をつかみ、記事をより信頼性が高く、読むことがより楽しいようにします。 本当に 8.5.5 あまりにも早くあきらめないで - 緊張の構築を維持する ほとんどのブログ投稿では、早期に TL;DR を共有することをお勧めしますので、読者はすぐに継続するかどうかを決めることができます。 ここではありません! バグハンティングのブログ投稿で、すべてのコストでスパイラーを避けてください! 緊張は、 aha の瞬間が起こるまで忍耐強く構築されなければなりません、そして修正が明らかになります。 これは、読者(少なくとも急いでいない人々)が狩りの興奮を、そのすべての回転と回転と共に体験するための鍵です。 彼らはすでに記事が幸せな結末で終わることを疑っているかもしれません、そうでなければ出版されません。 しかし、ほとんどの探偵ストーリーはそうではありませんか? 8.5.6 過剰な読者に修正のためのハードな狩りをしないでください もしかしたら、彼らはわずか数段落の後に自分自身の結論を出し、彼らが正しいことを確認する即座な満足を望むかもしれない、すぐに、馬鹿げた古いあなたとは異なり。おそらくこれは彼らが今月見つけた12番目のJavaバグハンティングブログ投稿であり、彼らはこれがゴミの収集者が最終的に責任を負うかどうかを確認したいと思います。 ボーナスとして、明確にラベル付けされた修正はまた、彼らが今、同じような問題に苦しんでいるので、あなたのブログ投稿に戻ってくる人々にとって有用です。これを読んで楽しみにしていたとき、彼らはあなたの狩りの興奮とともにそれに従うでしょう。しかし、テーブルが回転した今、彼らはあなたの修正に直接行って、それは彼ら自身の絶望の瞬間を救うかどうかを確認したいです。 8.5.7 必要に応じてブレークポイントを追加する Bug hunt articles can get long, especially if you’re covering every little twist and turn (as you absolutely should!) If you end up writing a blog post that will take over 20 minutes or so to read, consider adding a few clear breaking points for readers, in case they opt to consume your article in more than one sitting. たとえば、あなたはこれまでの調査の進捗状況の短い概要を提供することができます. あなたは、上記のステップが死に至るまで、新しい論文につながったという明確なメモを追加することができます. または、あなたは単に「第3段階」のようなサブタイトルを使用することができます。 8.5.8 人生を吸わないで 読者は公式の失敗レポートを読むためにここにはいません。魅力的なビットは、個人的なストーリー、戦い、そして何が間違っていたかを把握する最終的な喜びです。 Narrate it from your personal point of view. Don’t hesitate to share what was going through your mind as the mystery unfolded. Also, rants are borderline mandatory and expected – in reasonable doses, of course. Deep down, most humans enjoy reading about other people’s frustrations and feeling the indirect relief that it didn't happen to them (yet). 上記の「緊張を構築する」と「ヒントへの完全なアクセスを提供する」アプローチは、読者を関わらせる2つの基本的な方法です(はい、彼らは 本物の探偵物語から恥ずかしがらずに盗まれた) さらに、あなたは、あなたがしたいかもしれない: は Write in an extremely casual tone, sacrificing “proper” grammar as needed to keep it conversational Create a faux dialog with the reader: ask them questions so they’re encouraged to step back and form their own hypotheses (which you will proceed to confirm or disprove) Write as if you’re in the thick of the hunt (e.g., “Let’s see if …” vs. “Then we checked if…’’) Share exactly what popped into your head (no matter how silly it seems in retrospect) as you encountered each new piece of information Explicitly call out critical moments like “plot twist,” “dead end,” and “the aha moment” to ensure readers are in the right mindset at every point 8.5.9 狩りに協力してくれた人たちに感謝することを忘れないでください。 バグハウスはコンピュータプログラミングの最も怒る部分の1つであり、不幸は会社を愛する。あなたの協力者は、おそらく、痛みを少し減らすことができ、もしあなたがそれに感謝しているなら、ここで彼らに感謝します。それほど優しくない人々のために、あなたの協力者に感謝するための実践的な(読む:利己的)理由もあります。あなたの認知は、彼らが次のバグハウスで助ける可能性を高めることができます。また、あなたがブログの投稿で誰かを名前付けたら、彼らがそれを読むことをかなり保証することができます - そして、彼らはそれを共有するかもしれません。そして、彼らが知っている誰かがハッカーニュースでトレンドを始める人になるかもしれません。 8.5 エキストラ 特定のエラー(たとえば、「Rust コードにバグがあった」)からより一般的な問題(たとえば、「Rust 標準ライブラリはこの特定の使用例でドームロックを容易にする」)にエクストラポレートすることも自由です)バグ狩りブログの投稿は、特定のテクノロジーであなたが持っている痛みの点を明るくする機会です。あなたは、あなたが言うべきことに関心を持った囚人々を魅了することに成功しました。なぜそれを利用しないのですか? あなたが使用した言語やライブラリに関して特に問題のある何かを見つけた場合は、弾丸を噛み、何かを上流に修正することを示唆してください。プログラミング言語とライブラリのメンテナーは、プロジェクトを改善するのに役立つ建設 8.6 概要 バグハンティングの記事を書くことは、知識を共有し、遭遇したバグについての意識を高め、あなたの業績を展示するために役立ちます。 A bug hunting blog post targets a technical audience, from experts to enthusiasts, usually assuming (at least) intermediate knowledge of the terminology バグハンティングのブログ記事は、通常、調査の詳細に重く、数字、ベンチマーク、結果、グラフの形で技術的な証拠を示しています。 Top tips: Check for transparency issues Do a technical deep dive Be brutally honest Include numbers and benchmarks Avoid spoilers Clearly mark “the fix” Make it personal Thank your collaborators ♪♪♪ You can preview more of the book より多くの本を見ることができます。 (Don’t miss the そして ) ご注意ください、言葉は私たちのコントロールを超える何らかの見た目で任意の点で混乱していることに注意してください。 / ̄ マンニングサイト ブライアン・カントリル Bryan Cantrill afterword by Scott Hanselman (ツ)