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 Schreiben für Entwickler: Blogs, die gelesen werden Die Bug-Jagd Wir schreiben es in X neu Wie wir es gebaut haben Lektionen gelernt Gedanken über Trends Nicht-Marketing-Produkt Perspektiven Benchmarks und Testergebnisse ist Der Blogpostmuster "Bug Hunt" ist das Programmwelt-Äquivalent einer Detektivgeschichte. Es hat ein Thema, eine Hauptteil, Seitenpläne, einen Protagonisten (Sie), einen Antagonisten (in der Regel auch Sie, nachdem Sie den Bug vor zwei Wochen an erster Stelle eingeführt haben). Es ist faszinierend, hält die Leser in Aufregung und endet mit einer befriedigenden Handlungsschaltung oder einem taktischen Cliffhanger. 8.1 Zweck Das Schreiben eines Bug-Jagd-Artikels dient ein paar Zwecken, abhängig vom Erfolg der Jagd, wo der Fehler letztendlich fiel, und ein paar andere Faktoren. 8.1.1 Knowledge dump Die Tatsache, dass ein Bug erschien und behoben wurde, ist unbestreitbar wichtig. aber was noch wichtiger ist, ist die Wahrscheinlichkeit zu verringern, dass es wieder passiert – und zu wissen, was zu tun ist, wenn es passiert. Einige toten Enden Ein sehr überzeugender roter Hering A tool that looked helpful at first, but ended up being unrelated Ein weiteres Tool, das sich als äußerst nützlich erwiesen hat Einige Blogbeiträge aus dem Jahr 2014, die Sie zur Entdeckung der Ursache geführt haben Alle diese Schritte sind unglaublich nützlich für den zukünftigen Debugger eines anderen ähnlichen Problems (wahrscheinlich wieder, zwei Wochen älter). Das Bewusstsein der vergangenen toten Enden und Ablenkungen ist hier besonders hilfreich. Die schnelle Identifizierung eines bekannten roten Herings kann dem zukünftigen Debugger (Sie) ein paar Stunden unproduktiver Forschung ersparen. Sie können Bug-Jagd-Blog-Posts als Rollen alter Kenntnisse (zwei Wochen oder älter) behandeln, die von Ihren Vorgängern (Sie) geschaffen wurden, um sie an zukünftige Generationen (auch Sie) weiterzugeben. 8.1.2 Globales Bug Bewusstsein Wahrscheinlich gilt der Fehler, den Sie behoben haben, nicht eindeutig für Ihr Projekt. Stattdessen wurde er durch einen versteckten Fall in Ihrer gewählten Sprache, einer der Bibliotheken oder einer bestimmten Hardware verursacht. Ihr Artikel kann andere wirklich dazu inspirieren zu denken "Huh, wir haben genau die gleiche Einstellung - es macht mich wundern..." Es könnte auch das Team hinter dieser Technologie motivieren, Wege zu erwägen, andere davon abzuhalten, den gleichen Fehler zu machen. Als Ergebnis kann das Schreiben einer Geschichte darüber, wie Sie einen interessanten Bug behoben haben, dazu führen, dass einige andere Bugs der gleichen Kategorie weltweit behoben werden. Blutungen Edge Software Neue Hardware Eine junge Open Source-Community Diese entwickeln sich tendenziell dynamisch und haben im Vergleich zu Branchenstandards nur sehr wenig Testabdeckung, weil sie zu jung sind, um in einer kritischen Masse von Projekten umgesetzt zu werden. 8.1.3 Bragging Setzen Sie die negative Konnotation des Wortes „Bragging“ beiseite. Tech-Welt-Bragging – in der richtigen Dosierung – ist gut für Sie und Ihre Kollegen. Bragging über etwas Interessantes zu tun, wie das Jagen und das Beheben eines Bugs, hilft Ihnen und Ihren Lesern: 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 Das Publikum Bug-Jagd ist ein technisches Thema, und das Publikum für Bug-Jagd-Blog-Posts ist inhärent genauso technisch. Menschen mit einem ähnlichen Hintergrund (was bedeutet, dass sie potenziell anfällig für die Einführung oder leiden unter ähnlichen Bugs in ihren Systemen sind) Menschen, deren Aufgabe es ist, Produktionsfehler zu finden und zu beheben Menschen inmitten einer ähnlichen Bug-Jagd Personen, die in der Lage sein könnten, diese Klasse von Bugs vor Wiederholung zu verhindern (diejenigen hinter der Technologie, in der der Bug aufgetreten ist oder an Werkzeugen zur Fehlerverhütung arbeitet) Detective Fiction Liebhaber Your colleagues Professional Internet critics specialized in unsolicited advice It's safe to assume that the audience is someone who: Sie haben bereits ausreichend beruflichen Hintergrund, um die technischen Begriffe und Idiome zu verstehen, die Sie im Artikel verwenden If not, is willing to look them up and learn Wenn nicht, ist es absolut in Ordnung, nur so zu tun, als ob sie es verstehen. Daher ist es in Ordnung, einen Blogbeitrag zu behandeln, der auf "Mittelniveau" (oder höher) gerichtet ist und nicht auf "Neulinge" gerichtet ist.Erweiterte technische Begriffe sind in Ordnung, weil Sie nicht versuchen, den Artikel für die breitere Öffentlichkeit zugänglich zu machen. 8.3 Examples Da Bugs überall auftreten können, können auch Bug-Jagd-Blog-Beiträge.In der Wildnis können Sie Bug-Jagd-Beiträge finden, die über eine Vielzahl von Blogs veröffentlicht wurden: Big Tech, Unicorn, Startup und persönliche Blogs.Im Allgemeinen sind Bug-Jagd-Beiträge, die von großen hochkarätigen Unternehmen veröffentlicht werden, überraschend weniger häufig (und mehr bewacht) als die von Startups sowie einzelnen Beiträgen, die über Open-Source-Beiträge und Wochenendprojekte schreiben. Hier sind einige hervorragende Beispiele für Blog-Posts, die das Muster "Bug Hunt" anwenden, zusammen mit Piotr's Kommentar zu jedem. 8.3.1 Hunting a NUMA Performance Bug Michał Chojnowski Author: Blogs von Schröder ( ) Source: https://www.scylladb.com/2021/09/28/hunting-a-numa-performance-bug/ Summary Der Artikel beschreibt eine Performance-Regression auf moderner Hardware mit NUMA (Non-Uniform Memory Access) Design. Die Regression schien zufällig in der Hälfte der Läufe auftreten, was es viel schwieriger machte, festzustellen. Der Artikel teilt ein paar gescheiterte (aber dennoch geschickte und beeindruckende) Versuche, das Problem zu diagnostizieren. Commentary Dies ist der Höhepunkt der Bug-Jagd-Blog-Posts. Es ist tief technisch, aber gleichzeitig einfach zu folgen. Die weniger erfahrenen Leser können einige der nitty-gritty-Details überspringen und immer noch viel lernen. Die zufällige Expertise, die der Autor beim Bearbeiten von ausführbaren Binären direkt zeigt, als ob sie Textdateien wären, macht den Blog-Post zu einem äußerst angenehmen Lesen.Die Lösung des Problems ist auch sehr befriedigend, besonders für den Geist eines Programmierers: Nur eine scheinbar unschuldige Zeile des Codes wurde geändert und alle Leistungsregressionen werden beseitigt. 8.3.2 Why Is My Rust Build So Slow? Amos Wenger Author: Blogeinladung ( Source: https://fasterthanli.me/articles/why-is-my-rust-build-so-slow) Summary Dieser umfangreiche Blogbeitrag untersucht Kompilationszeitprobleme für ein Rust-Projekt. Es zeigt mehrere Techniken, wie man den Compiler selbst profiliert, den Kompilationsprozess in verwaltbare Stücke zerlegt und misst, wie lange jedes Stück dauert und warum. Es ist voll von Bildern, Code-Snippets und Beschreibungen von konkreten Werkzeugen, die Sie verwenden können. Die Schlussfolgerung des Artikels ist nicht wirklich ein einziger Durchbruch, sondern eher ehrliche Ratschläge, alle oben genannten umfangreichen Techniken anzuwenden, wenn Sie mit Ihrer Rust-Build-Zeit unzufrieden sind. Commentary Im Vergleich zu einem durchschnittlichen technischen Blogbeitrag ist dies ein Hog – im rein positiven Sinne!Es kann leicht einen erfahrenen Leser eine halbe Stunde dauern, um es durchzulesen, und es ist wahrscheinlich eine gute Idee, es in drei oder vier Teile zu verdauen, Pausen vom Bildschirm zu nehmen, um Schwindel und Diplopie zu vermeiden. This is a positive trait because it makes the article stand out. Many tech articles try to squeeze as much information as possible into 4 to 6 minutes of reading. And that’s fair, considering the average attention span of a human being raised on smartphones rather than playing outside all day with occasional cartoon breaks. Yet, a long article will appeal to the old school folks who were once capable of reading a book in a single sitting. The article has a unique style featuring the author's alter ego, Cool Bear, who regularly adds short humorous comments – keeping the reader engaged throughout the (lengthy) reading process. Diese Art von Bug-Jagd-Blog-Beitrag dient auch als Enzyklopädie von Techniken für das Debuggen des Rust-Compilers. Ich habe es markiert, nur für den Fall, dass ich jemals mein Wissen über die Messung von Verbindungszeiten in meinen Projekten aktualisieren muss. Die Schlussfolgerung ist auch ziemlich unkonventionell: Anstatt Spannung aufzubauen und den Lesern schließlich eine Überraschungslösung zu präsentieren, ist es einfach eine ehrliche Zusammenfassung mit Ermutigung, sich auszurichten. 8.3.3 How a Single Line of Code Made a 24-core Server Slower Than a Laptop Piotr Kołaczkowski Author: Der Blog von Piotr Kołaczkowski ( ) Source: https://pkolaczk.github.io/server-slower-than-a-laptop/ Summary Der Blogbeitrag beschreibt, wie lokale Benchmarks auf Maschinen mit vielen CPU-Kernen ein Flaschengehalt erkannt haben.Der Autor teilt eine Leistungsanalyse, führt einige Profiling durch, bietet dann ein paar Erklärungen darüber, wie moderne CPUs unter der Kappe funktionieren und wie die Prozessor-Caches Speicher verwalten.Die vorgeschlagene Fix ist eine natürliche Folge der Schlussfolgerungen, die zuvor im Artikel erreicht wurden: Die Minimierung der Menge des Zustands, der zwischen Prozessor-Einheiten geteilt wird, beseitigt die Flaschengehalt. Commentary Sein Titel ist ein wenig clickbaity, aber immer noch elegant genug, um von der durchschnittlichen ad-blocking-software abgelehnt zu werden. Der Artikel ist scheinbar pädagogisch, indem er Dinge wie "Wie viele Nanosekunden nimmt der L3-Cache-Zugriff im Durchschnitt auf Intel Xeon ein." Das ist eine großartige Praxis; es hinterlässt diese Details in den Köpfen der Leser, ohne dass sie es merken. 8.3.4 Lektionen aus dem Debuggen eines Tricky Direct Memory Leak von Sanchay Javeria Author: Pinterest Ingenieur Blog ( ) Source: https://medium.com/pinterest-engineering/lessons-from-debugging-a-tricky-direct-memory-leak-f638c722d9f2 Summary Das Entwicklungsteam von Pinterest teilt ihre Erfahrungen mit der Jagd auf ein Leck aus dem Speicher von Stream-Verarbeitungscodes, das zu Cascading-Fehlern in ihrem verteilten System geführt hat. Commentary Dies ist ein klassischer Bug-Jagd-Artikel – so viel, dass es als Blog-Post-Vorlage verwendet werden könnte, um fast jedes Problem im Java-Code zu jagen. Es enthält die üblichen Untersuchungsschritte, zusammen mit Screenshots von Beobachtungs-Tools. Auch nach Bedienung wird der Höhepunkt Absatz "The Fix" genannt. Es erklärt, dass der Täter ein weiteres Problem mit Speicherleckungen war, das indirekt durch Müllsammelmechanismen in Java verursacht wurde. Hinweis: Es ist immer! In diesem Zusammenhang ist die Schlussfolgerung nicht wirklich ein erdrückender Durchbruch, aber sie erfüllt definitiv die Erwartungen der Leser. ich wette, die Mehrheit der Leser denkt "Ah, ich wusste es von Anfang an" direkt nach dem Lernen der Ursache. 8.3.5 ZFS isst meine CPU geheimnisvoll Brendan Gregg Author: Der Blog von Brendan Gregg ( ) Source: https://www.brendangregg.com/blog/2021-09-06/zfs-is-mysteriously-eating-my-cpu.html Summary The blog post describes a hunt for the cause of mysterious higher-than-expected CPU usage. It shows how to narrow the candidates down to a single function call with analysis tools and concludes with a surprising performance bug in ZFS – a file system implementation. Commentary Der Titel selbst ist faszinierend, aber dann springt etwas in der URL auf Sie: Es ist von Brendan Gregg, dem Flame-Graph-Erfinder! Dies ist ein hervorragendes Beispiel dafür, warum persönliche Marke so viel zählt. Angesichts der Expertise von Gregg war die Problemanalyse natürlich mit Flammendiagrammen verbunden. Die Ursache ist ziemlich überraschend, und Gregg beschrieb es auf sehr informelle und lustige Weise. Der Blogbeitrag ist auch sehr konzentriert: eine dreiminütige Lektüre, auch wenn Sie etwas Zeit im Voraus reservieren, um die Flammendiagramme zu betrachten. Es zeigt deutlich, dass Sie nicht Tausende von Wörtern schreiben müssen, um viel Wissen, Tipps und interessante technische Details zu prüfen. Siehe jüngere „Bug Hunt“ Blogbeiträge auf writethat.blog Lesen Sie die neuesten „Bug Hunt“ Blogbeiträge Schreiben Sie hier.Blog Schreiben Sie hier.Blog 8.4 Characteristics Bug Hunt Blog-Posts können so wild variieren wie die tatsächlichen Bug-Jagd - aber sie neigen dazu, die folgenden Eigenschaften zu teilen: Sie erzählen die Geschichte chronologisch, von dem Moment an, als sich der böse Bug manifestierte, bis zu dem Zeitpunkt, als er tot erklärt wurde. They focus primarily on the thrill (and pain) of the hunt They freely share the evidence collected along the hunt so readers can put on their detective hats and play along Sie richten sich hauptsächlich an erfahrene Entwickler, die die diskutierten Technologien kennen (oder bereit sind, wie sie gehen zu lernen) Sie bieten technische Nuggets, die jetzt interessant sein könnten, Leben retten später Lassen Sie uns jeden auf der Reihe untersuchen. 8.1 Chronologisch geformt Bug-Jagd-Blog-Posts folgen oft einer spezifischen Struktur, da sie das technologische Äquivalent von Detektivgeschichten sind. (Wenn Sie eine Einführung oder eine Erfrischung der Struktur einer Detektivgeschichte wollen, macht generative AI hier eine anständige Arbeit). Der Einführungsabschnitt enthüllt nicht zu viele Details und bietet sicherlich keinen Spoiler auf die Lösung. Once the problem is defined, the hunt begins, usually with a few failed (but educational) attempts. The tension builds until the author reaches their aha moment, which is followed by the fix description (and that section is customarily titled "The Fix"). After the solution is revealed, the blog post concludes by describing preventive measures to stop this bug from recurring – and often a concise apology to any affected users. 8.4.2 Schwer auf der Jagd The meatiest part of the article is the path towards identifying the issue. Spending around 80% of the post explaining the investigation process is a good rule of thumb. For example, here’s how much time each of the example blog posts above spent on the investigation (based on word count): 85% hunt Chojnowski: 83% hunt Wenger: 83% hunt Kołaczkowski: 82% hunt Javeria: 93% hunt Gregg: 8.3 Beweise überall Bug-Jagd-Blog-Posts sind in der Regel voller forensischer Beweise. Leser wollen Flammendiagramme, Zahlen, Charts, Skripte und Code-Proben sehen. Dies lässt sie in Ihre Detektivschuhe steigen und versuchen, das Rätsel vor der großen Enthüllung herauszufinden. Hier sind zum Beispiel einige der Beweise, die in den Beispiel-Blog-Posts gezeigt werden: Database monitoring graphs (writes per shard), network and disk performance graphs, CPU stats, flame graphs and instruction-level breakdowns, the CPU’s performance measuring monitoring unit (PMU) events, and a variety of attempted code fixes Chojnowski: Wenger: Cargo Build Timings, eine Zeitleiste von Compilationseinheiten, CPU-Nutzung und Konkordanzgrafiken, Debug-Informationen, Flame-Grafiken, Tracking durch Chromium und Perfetto, versuchte Code-Fixes, Abhängigkeitsgrafiken Kołaczkowski: Ein Blick auf das Design des Benchmarking-Tools, Durchsatzergebnisse (auf seinem 4-Kern-Laptop vs. einem 24-Kern-Server), Flame-Diagramme Javeria: Fehlerdetails außerhalb des Gedächtnisses, Backpressure-Tests und mehrere Eingriffe in die Speicherüberwachung Gregg: Flame-Grafiken (natürlich!), ZFS-Montagen-Details, Arcstats und der gesamte Quellcode, über einen GitHub-Link Flame-Diagramme sind besonders häufig in Bug-Jagd-Blog-Posts. Sie bieten eine großartige Möglichkeit, Ihren Debugging- und Performance-Profiling-Prozess zu visualisieren. Und sie sind interaktiv - Benutzer können auf die interessanten Teile zoomen, nur die Ereignisse filtern, die einem bestimmten regulären Ausdruck entsprechen, und vieles mehr. 8.4.4 Expert friendly Bug-Jagd-Artikel neigen dazu, Expertenfreundlich zu sein. Der Autor geht in der Regel davon aus, dass das Publikum mit dem in dem Artikel verwendeten technologischen Stapel geschickt (oder zumindest vertraut) ist. Code-Proben und Skripte, die im Artikel geteilt werden, richten sich in der Regel an Leser, die mit den verwendeten Programmiersprachen vertraut sind. Dies unterscheidet sich deutlich von anderen Blog-Post-Muster, wie "Wir haben es in X neu geschrieben" (gesprochen in Kapitel 9). Blog-Posts in diesem Muster sind besser geeignet für diejenigen, die gerade mit der gegebenen Technologie beginnen und enthalten oft einen Abschnitt "Einführung in die neue Sprache". 8.4 Bildung Blog-Posts, die diesem Muster folgen, können für Entwickler über das betroffene Team hinaus ziemlich pädagogisch sein. Der fleischige Teil, die Bug-Identifizierung, ist reichlich in Details darüber, wie man ähnliche Probleme überprüft. Noch wichtiger ist, dass diese Abschnitte reichlich in reproduzierbaren Details sind: diejenigen, die wahrscheinlich nützlich sind, um alle Arten von ähnlichen Problemen zu lösen, mit denen Leser in der Zukunft konfrontiert sein könnten. Der Blog-Post dient seinem Zweck, wenn er den Leser mit ein paar weiteren Tricks ausgestattet lässt, die sie anwenden können, nur falls sie jemals einen ähnlichen Bug irgendwann in ihrem Leben begegnen. For example, here’s a high-level view of what readers could learn from each of our example blog posts: 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.5 Dos und Don'ts The best blog posts are born from the most torturous bug hunts. Driven by the glorious feeling of finally solving the mystery, strike while the iron is hot. Write your impressions before the high of the hunt wears off and help your peers solve their next case faster. Here are some tips for writing your own Bug Hunt blog post. 8.5.1 Überprüfen Sie, ob jemand (Ihr Chef, die Anwälte Ihres Chefs) durch Ihre Transparenz gestört wird This is especially important if you hunted a bug that had a notable impact on users – or if the disclosure of this bug could negatively impact your company’s reputation and/or the all-important stock price. Open-source or source-available projects usually don’t impose any legal considerations (except maybe trying to avoid getting your code infected with one of the GPL licenses and its "copyleft" terms). Not all code is open-source though. Bevor Sie Codeabzüge Ihrer stark bewachten Unternehmensgeheimnisse veröffentlichen, stellen Sie sicher, dass Ihr Chef und alle interessierten Parteien damit in Ordnung sind.Selbst wenn Sie den Code überspringen, können Ihre Vorgesetzten immer noch ablehnen, bestimmte Informationen öffentlich zu machen, insbesondere wenn der Fehler mit Sicherheit zu tun hatte oder mit einem unglücklichen Datenleck endete. Verwenden Sie diese Daumenregel: Fragen Sie zuerst, schreiben und veröffentlichen Sie später. 8.5.2 Machen Sie ein technisches tiefes Tauchen Technical details are a must in any, well, 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 Seien Sie brutal ehrlich über alle Ihre Fehler Ihre Misserfolge und Elend geben den Lesern den kataraktischen Effekt, der sie zuerst zu Ihrem Blogbeitrag brachte! Sie geben auch den Bildungsaspekt der Bug-Jagd-Artikel hervor.Nach allem ist es großartig, aus Fehlern zu lernen, aber es ist noch besser, zuerst von den Fehlern anderer zu lernen. Bug hunting blog posts are usually written after the root cause has been identified and the bug fixed. The more pain and suffering are described in the first paragraphs, the better the final breakthrough looks. Readers who struggle with similar issues are going to actively search the Internet for descriptions of similar problems, so all the sorrowful keywords like "broken," "fault," or "FUBAR" serve dual purposes – they're an emotional outlet for the author's frustration, plus they also make the blog post easier to find online. Don't try to convey a perfect, pristine bug hunt. Dead ends and failed attempts bring in tons of educational value. Programmers (which is of course a synonym for “great minds”) think alike. That means some readers could get stuck in the same dead ends – unless they read your cautionary tale first. 8.5.4 Zahlen, Benchmarks, Metriken und Flammendiagramme enthalten Benchmark-Ergebnisse, Metriken und alle Arten von Zahlen sind das Äquivalent von Hinweisen und Beweisen aus der Welt der Detektivfiction. Bug-Jagd-Blog-Posts sehen weniger legitim aus, wenn sie vage Phrasen wie "unser System ist jetzt viel schneller" verwenden. proud of the results, then you would have posted them…" Screenshots from your metrics (or even better, interactive figures like flame graphs) catch readers' eyes, making the article both more credible and more enjoyable to read. really 8.5.5 Don't give away too much, too soon – keep the tension building For most blog posts, we recommend sharing the TL;DR early on so readers can quickly decide if they want to continue. Not here! With bug hunt blog posts, avoid spoilers at all costs! The tension should be patiently built until the aha moment occurs, and the fix is revealed. This is key for allowing readers (those not in a hurry, at least) to vicariously experience the thrill of the hunt, with all its twists and turns. They probably already suspect that the article concludes with a happy ending, because otherwise it wouldn't be published. But aren't most detective stories like that anyway? 8.5.6 Machen Sie nicht übermäßige Leser zu hart für die Reparatur jagen Das heißt, einige Leser werden ungeduldig. Vielleicht haben sie ihre eigenen Schlussfolgerungen nach nur wenigen Absätzen gezogen und wollen die sofortige Befriedigung, zu bestätigen, dass sie es richtig haben, sofort, im Gegensatz zu dummen alten Ihnen. Vielleicht ist dies der zwölfte Java-Bug-Jagd-Blog-Post, den sie in diesem Monat getroffen haben, und sie wollen sehen, ob dies ein weiterer ist, wo der Müllsammler letztendlich die Schuld hat. Seien Sie freundlich und markieren Sie "die Fix" mit einer schönen prominenten Überschrift, damit sie auf die Rauchgewehr springen können. As a bonus, having a clearly labeled fix is also helpful to those who are returning to your blog post because they’re now suffering a similar problem. Back when they were reading this for fun, they enjoyed following along with the thrill of your hunt. But now that the tables have turned, they want to go straight to your fix and see if it will save them in their own moment of despair. 8.5.7 Add breaking points wherever necessary Bug-Jagd-Artikel können lang werden, vor allem, wenn Sie jede kleine Wendung und Drehung abdecken (wie Sie unbedingt sollten!) Wenn Sie am Ende einen Blogbeitrag schreiben, der mehr als 20 Minuten dauern wird, um zu lesen, sollten Sie einige klare Bruchpunkte für Leser hinzufügen, falls sie sich entscheiden, Ihren Artikel in mehr als einer Sitzung zu konsumieren. Sie könnten eine explizite Anmerkung hinzufügen, dass die oben beschriebenen Schritte zu einem toten Ende führten, was zu einer neuen These führte. oder Sie könnten einfach Untertitel wie „Phase 3“ verwenden, die dem Leser subliminal vorschlagen, dass es in Ordnung ist, hier eine kurze Kaffeepause zu machen, ohne den Kontext zu verlieren. 8.5.8 Saugen Sie das Leben nicht aus ihm Readers aren't here to read an official failure report. The captivating bits are the personal story, the struggle, and the final joy of figuring out what was wrong. The best bug hunting blog posts use an informal conversational tone, and anecdotes are very much welcome. Erzählen Sie es aus Ihrer persönlichen Perspektive. Zögern Sie nicht, zu teilen, was durch Ihren Geist ging, als das Geheimnis entfaltet. Auch Rennen sind Grenzlinie obligatorisch und erwartet – in vernünftigen Dosen, natürlich. Tief in der Tiefe, die meisten Menschen genießen das Lesen über die Frustrationen anderer Menschen und das Gefühl, die indirekte Erleichterung, dass es ihnen nicht passiert (noch). Die oben erläuterten Ansätze "Spannung aufbauen" und "vollständiger Zugang zu Hinweisen" sind zwei grundlegende Wege, um die Leser zu engagieren (ja, sie schamlos gestohlen von echten Detektivgeschichten).Darüber hinaus möchten Sie vielleicht: sind 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 Vergessen Sie nicht, diejenigen zu danken, die während der Jagd geholfen haben Der wichtigste Grund für die öffentliche Anerkennung Ihrer Mitarbeiter ist reine Freundlichkeit. Bug-Jagd gehört zu den wütendsten Teilen der Computerprogrammierung, und Elend liebt Unternehmen. Ihre Mitarbeiter haben wahrscheinlich den Schmerz ein wenig weniger erschreckend gemacht; wenn Sie das überhaupt schätzen, danken Sie ihnen hier. Für die nicht-so-empathischen Leute gibt es auch pragmatische (lesen: egoistisch) Gründe, Ihre Mitarbeiter zu danken. Ihre Anerkennung könnte sie wahrscheinlicher machen, bei der nächsten Bug-Jagd zu helfen. Auch, wenn Sie jemanden in einem Blogbeitrag benennen, können Sie ziemlich garantieren, dass sie es lesen – und vielleicht werden sie es sogar teilen. Und vielleicht wird jemand, den sie wissen, die Person sein, um es auf Hacker News zu trenden. 8.5.10 Extrapolate Feel free to extrapolate from specific errors (e.g., "Our Rust code had a bug") into more general issues (e.g., "Rust standard library makes it easy to deadlock in this particular use case.") Bug hunting blog posts are also opportunities to shine some light on pain points you have with a particular technology. You’ve managed to attract a captive audience, interested in what you have to say. Why not take advantage of that? If you noted something particularly problematic with the language or library you used, bite the bullet and suggest that something should be fixed upstream. Programming language and library maintainers appreciate constructive criticism that helps improve their projects. 8.6 Zusammenfassung Das Schreiben eines Bug-Jagd-Artikels dient dazu, Wissen zu teilen, das Bewusstsein für Bugs zu erhöhen, mit denen Sie konfrontiert sind, und Ihre Erfolge zu präsentieren. A bug hunting blog post targets a technical audience, from experts to enthusiasts, usually assuming (at least) intermediate knowledge of the terminology Bug hunting blog posts are typically heavy on investigative details, showcasing technical evidence in the form of numbers, benchmarks, results, and graphs 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 und Bitte beachten Sie, dass die Wörter an einem scheinbar willkürlichen Punkt außerhalb unserer Kontrolle gestört werden. / ̄ Auf der Manning-Website foreword by Bryan Cantrill afterword by Scott Hanselman (ツ)
