Die volgende post is 'n uittreksel uit Hoofstuk 8 van Skryf vir Ontwikkelaars: blogs wat gelees word deur Piotr Sarna en Cynthia Dunlop. Skryf vir ontwikkelaars: blogs wat gelees word Die Bug Hunt Ons skryf dit in x Hoe ons dit gebou het Leksies geleer Gedagtes oor trends Non-market produk perspektiewe Benchmarks en toetsresultate die Die “Bug Hunt” blogpos patroon is die programmering wêreld se ekwivalent van 'n detektiwiteitsverhaal. Dit het 'n tema, 'n hoof plot, side plots, 'n hoofspeler (jy), 'n antagonis (gewoonlik ook jy, het die fout twee weke gelede in die eerste plek ingevoer). Dit is fassinerend, hou lesers in suspense, en eindig met 'n bevredigende plot draai, of 'n taktiese cliffhanger. 8.1 Die doel Die skryf van 'n bug jag artikel dien 'n paar doeleindes, afhangende van die sukses van die jag, waar die fout uiteindelik val, en 'n paar ander faktore. 8.1.1 Kennis van die afval Die feit dat 'n fout verskyn en opgelos is, is ongetwyfeld belangrik.Maar wat nog belangriker is, is om die kans te verminder dat dit weer gebeur - en om te weet wat om te doen as dit gebeur. 'n Paar dooies eindig 'N baie oortuigende rooi herring 'N Tool wat aanvanklik nuttig lyk, maar uiteindelik nie verband hou nie Nog 'n instrument wat buitengewoon nuttig was Sommige blogpos van 2014 wat jou gelei het om die worteloorsaak te ontdek Al hierdie stappe is ongelooflik nuttig vir die toekomstige debugger van 'n ander soortgelyke probleem (waarskynlik jy weer, twee weke ouer). Bewustheid van die verlede dood eindig en afleiding is veral nuttig hier. Vinnig identifisering van 'n bekende rooi hering kan die toekomstige debugger (jy) spaar 'n paar uur van onproduktiewe navorsing. Jy kan bug jag blog poste behandel as rulle van antieke kennis (twee weke of ouer), wat deur jou voorgangers (jy) geskep is om dit aan toekomstige geslagte (ook jy) oor te dra. 8.1.2 Globale bug bewustheid Dit is terugkeer-tot-die-gemeenskap tyd! Die kans is, die fout wat jy opgelos het, is nie uniek van toepassing op jou projek nie. In plaas daarvan, dit is veroorsaak deur 'n bedrieglike val in jou taal van keuse, een van die biblioteke, of spesifieke hardeware. Jou artikel kan werklik ander inspireer om te dink "Huh, ons het presies dieselfde instelling - maak my wonder ..." Dit kan ook die span agter daardie tegnologie motiveer om maniere te oorweeg om ander te stop om dieselfde fout te maak. As gevolg hiervan kan die skryf van 'n storie oor hoe jy 'n interessante fout opgelos het, veroorsaak dat 'n paar ander bugs van dieselfde kategorie wêreldwyd opgelos word. Dit is 'n supermag! Hierdie doel is veral belangrik as die fout verband hou met: Bloeding Edge sagteware Nieu Hardware 'N Jong open-source gemeenskap Hulle is geneig om dinamies te ontwikkel en het baie min toetsdekking in vergelyking met industriestandaarde eenvoudig omdat hulle te jong is om in 'n kritieke massa projekte te implementeer. 8.1 Bragging Gooi die negatiewe connotasie van die "bragging" woord af. Tech-wêreld-bragging - by die regte dosis - is goed vir jou en jou eweknieë. Bragging oor iets interessant te doen, soos jag en 'n fout op te los, help jou sowel as jou lesers: 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 Die publiek Bug jag is 'n tegniese onderwerp, en die gehoor vir bug jag blog poste is inherent net so tegniese. Mense met 'n soortgelyke agtergrond (wat beteken dat hulle potensieel vatbaar is vir die invoering of ly aan soortgelyke bugs in hul stelsels) Mense wie se werk is om produksie bugs te vind en te herstel Mense in die middel van 'n soortgelyke bug jag Mense wat hierdie klas van bugs kan voorkom om terug te keer (diegene agter die tegnologie waar die bug plaasgevind het of werk aan gereedskap vir die voorkoming van foute) Detective fiction aficionados Your colleagues Professionele Internet-kritikus wat spesialiseer in ongevraagde advies Dit is veilig om aan te neem dat die gehoor iemand is wat: Al genoeg professionele agtergrond om die tegniese terme en idiome wat jy in die artikel gebruik, te verstaan Indien nie, is bereid om hulle te kyk en te leer Indien nie, is dit absoluut goed om net te doen asof hulle dit verstaan Daarom is dit goed om 'n blogpos te behandel as een wat gericht is op "middellange vlak" (of bo) lesers en nie "nu-komende". Geavanceerde tegniese terme is goed omdat jy nie probeer om die artikel toeganklik te maak aan die breër publiek nie. 8.3 Voorbeelde Since bugs can occur anywhere, so can bug hunting blog posts. In the wild, you can find bug hunting posts published across a variety of blogs: Big Tech, unicorn, startup, and personal blogs. In general, bug hunting posts published by large high-profile companies are unsurprisingly less common (and more guarded) than those by startups as well as individual contributors writing about open-source contributions and weekend projects. Hier is 'n paar voorbeelde van blogposse wat die "Bug Hunt" patroon toepas, saam met Piotr se kommentaar op elkeen. 8.3.1 Die jag van 'n NUMA-prestasie bug Michał Chojnowski Author: Skepper van die blog ( ) Source: https://www.scylladb.com/2021/09/28/hunting-a-numa-performance-bug/ Summary Die artikel beskryf 'n prestasie regressie wat op moderne hardeware gebeur met NUMA (Non-Uniform Memory Access) ontwerp. Die regressie het blykbaar willekeurig op die helfte van die hardloop plaasgevind, wat dit baie moeiliker gemaak het om te bepaal. Die artikel deel 'n paar mislukte (maar tog vaardige en indrukwekkende) pogings om die probleem te diagnoseer. Commentary Dit is die piekpunt van bug jag blog poste. Dit is diep tegniese, maar terselfdertyd eenvoudig om te volg. Die minder ervare lesers kan 'n paar van die nitty-gritty besonderhede spring en nog steeds baie leer. Al die mislukte pogings om die probleem te diagnoseer is opvoedkundig, en beslis nuttig in toekomstige debugging. Die toevallige kundigheid wat die skrywer toon tydens die bewerking van uitvoerbare binaries direk asof dit tekslêers was, maak die blogpos 'n uiters aangename lees. 8.3.2 Waarom is my rust bou so stadig? Amos Wenger Author: Verwys na die blog ( Source: https://fasterthanli.me/articles/why-is-my-rust-build-so-slow) Summary Hierdie uitgebreide blogpos ondersoek kompilering tyd kwessies vir 'n Rust projek. Dit toon verskeie tegnieke vir hoe om die kompiler self te profiel, die kompilering proses in bestuurbare stukke te ontbind, en meet hoe lank elke stuk neem en hoekom. Dit is vol van beelde, kode snippets, en beskrywings van konkrete gereedskap wat jy kan gebruik. Die artikel se gevolgtrekking is nie regtig enige enkele deurbraak nie, maar eerder eerlike advies om al die uitgebreide tegnieke hierbo toe te pas as jy nie tevrede is met jou Rust bou tyd. Commentary In vergelyking met 'n gemiddelde tegniese blogpos, is hierdie een 'n haak - in 'n suiwer positiewe sin! Dit kan maklik 'n vaardige leser 'n halfuur neem om dit te lees, en dit is waarskynlik 'n goeie idee om dit in drie of vier dele te verteer, pauzes van die skerm te neem om duisternis en diplopia te vermy. Dit is 'n positiewe kenmerk omdat dit die artikel onderskei. Baie tegniese artikels probeer soveel inligting as moontlik in 4 tot 6 minute van lees te druk. En dit is regverdig, aangesien die gemiddelde aandagsperiode van 'n mens op smartphones verhoog word eerder as om die hele dag buite te speel met af en toe cartoon breek. Die artikel het 'n unieke styl met die skrywer se alter ego, Cool Bear, wat gereeld kort humoristiese kommentaar byvoeg - hou die leser betrokke gedurende die (lang) leesproses. die Hierdie soort van 'n bug jag blog post dien ook as 'n encyklopedie van tegnieke vir die debugging van die Rust kompiler. Ek het dit boekmerk, net in die geval ek ooit nodig het om my kennis van hoe om koppelings tyd in my projekte te meet verfris. Die gevolgtrekking is ook redelik onkonvensionele: in plaas daarvan om spanning op te bou en uiteindelik lesers met 'n verrassing oplossing te bied, is dit net 'n eerlike opsomming met aanmoediging om te bereik. 8.3.3 Hoe 'n enkele lyn kode 'n 24-kern-bediener trager gemaak het as 'n laptop Piotr Kołaczkowski Author: Skepper van die Skepper se blog ( ) Source: https://pkolaczk.github.io/server-slower-than-a-laptop/ Summary Die blogpos beskryf hoe plaaslike benchmarks 'n bottleneck op masjiene met baie CPU-kerns gedetekteer het. Die skrywer deel 'n prestasie-analise, voer 'n paar profilering uit, bied dan 'n paar verduidelikings van hoe moderne CPU's onder die hoed werk en hoe die prosessor caches geheue bestuur. Commentary Dit is nog 'n sterre voorbeeld van 'n bug jag blog post. Sy titel is 'n bietjie klikbaity, maar nog steeds elegansie genoeg om te vermy word deur die gemiddelde ad-blokkering sagteware. Die tegniese besonderhede is baie meer universeel verstaan as diegene in Chojnowski se NUMA blog post (beskryf eerder in hierdie afdeling). Die artikel is sneakily opvoedkundig, digressing op dinge soos "Hoeveel nanosekondes neem L3 cache toegang neem gemiddeld op Intel Xeon." Dit is 'n goeie praktyk; dit laat daardie besonderhede in die lesers se gedagtes sonder dat hulle besef dit. wie weet - miskien een dag dat tucked-out tip kan help om 'n prestasie bug in 'n ander projek op te los. 8.3.4 Leerstellings van die Debugging van 'n Tricky Direct Memory Leak Sanjay Javeria Author: Instruksies vir die ontwerp van webwerwe ( ) Source: https://medium.com/pinterest-engineering/lessons-from-debugging-a-tricky-direct-memory-leak-f638c722d9f2 Summary Pinterest se ontwikkelingsteam deel hul ervaring met die jag van 'n stroomverwerkingskode geheue lek wat gelei het tot cascading mislukkings in hul verspreide stelsel. Commentary Dit is 'n klassieke bug jag artikel - soveel sodat dit kan gebruik word as 'n blog post sjabloon vir die jag na byna enige probleem in Java kode. Dit bevat die gebruiklike ondersoek stappe, saam met screenshots van waarneming gereedskap. Ook na die gebruik, die kulminasie paragraaf is genoem "The Fix." Dit verduidelik dat die skuldige was nog 'n geheue lek probleem wat indirek veroorsaak word deur rommel versameling meganismes in Java. Tip: Dit is altyd! In hierdie konteks is die gevolgtrekking nie regtig 'n aardverskriklike deurbraak nie, maar dit voldoen beslis aan die lesers se verwagtinge. ek wed dat die meerderheid van die lesers dink "Ah, ek het dit van die begin af geweet" net nadat die worteloorsaak geleer is. 8.3.5 ZFS is mysterieus eet my CPU Brendan Gregg Author: Brendan Gregg’s Blog ( ) Source: https://www.brendangregg.com/blog/2021-09-06/zfs-is-mysteriously-eating-my-cpu.html Summary Die blogpos beskryf 'n jag vir die oorsaak van geheimsinnige hoër-van-verwagte CPU gebruik. Dit wys hoe om die kandidate te beperk tot 'n enkele funksie oproep met analitiese gereedskap en eindig met 'n verrassende prestasie bug in ZFS - 'n lêer stelsel implementasie. Commentary Die titel self is fassinerend, maar dan spring iets in die URL op jou uit: dit is deur Brendan Gregg, die flame graph uitvinder! Dit is 'n goeie voorbeeld van hoekom persoonlike handelsmerk so belangrik is. Wanneer ek "Brendan Gregg" sien, neem ek dadelik aan dat die artikel interessant is ... en ek was nie in die geringste fout nie. Gegewe Gregg se kundigheid, het die probleemanalise natuurlik flame graphs betrokke gehad. Die worteloorsaak is nogal 'n verrassing, en Gregg het dit op 'n baie informele en grappige manier beskryf. Die blogpos is ook baie kort: 'n drie-minuut lees, selfs as jy 'n bietjie tyd vooraf reserveer om na die flame graph screenshots te kyk. Dit toon duidelik dat jy nie duisende woorde hoef te skryf om baie kennis, wenke en interessante tegniese besonderhede te druk nie. Sien meer onlangse “Bug Hunt” blog poste op writethat.blog Sien meer onlangse “Bug Hunt” blog poste Ek skryf.blog Ek skryf.blog 8.4 Die kenmerke Bug Hunt blog poste kan so wild as die werklike bug jagte verskil - maar hulle is geneig om die volgende kenmerke te deel: Hulle vertel die storie chronologies, van die oomblik dat die bose bug manifesteer, tot wanneer dit dood verklaar is. Hulle fokus hoofsaaklik op die opwinding (en pyn) van die jag Hulle deel vrylik die bewyse wat langs die jacht versamel is, sodat lesers hul detektiwitiese hoede kan dra en speel. Hulle is hoofsaaklik gerig op ervare ontwikkelaars wat die tegnologieë ken wat bespreek word (of gereed is om te leer as hulle gaan) Hulle bied tegniese nuggets wat nou interessant kan wees, later lewe red Kom ons ondersoek elkeen op sy beurt. 8.1 Geskryf chronologies Blogposte volg dikwels 'n spesifieke struktuur aangesien hulle die tegnologiese ekwivalent van detektiwiteitstories is. (As jy 'n inleiding of verfrissing van die struktuur van 'n detektiwiteitstory wil hê, doen generatiewe AI hier 'n ordentlike werk). Die inleidende paragraaf onthul nie te veel besonderhede nie en bied beslis nie 'n spoiler oor die oplossing nie. Sodra die probleem gedefinieer is, begin die jag, gewoonlik met 'n paar mislukte (maar opvoedkundige) pogings. Die spanning bou totdat die skrywer hul aha-moment bereik, wat gevolg word deur die fiks beskrywing (en daardie afdeling is gewoonlik getiteld "The Fix"). 8.4.2 Swaar op die jag Om ongeveer 80% van die pos wat die ondersoekproses verduidelik, te spandeer, is 'n goeie duimregel. 85% hunt Chojnowski: 83% hunt Wenger: 83% hunt Kołaczkowski: 82% hunt Javeria: 93% hunt Gregg: 8.3 Bewyse ooral Bug hunt blog posts are usually full of forensic evidence. Readers want to see flame graphs, numbers, charts, scripts, and code samples. This lets them step into your detective shoes and try to figure out the riddle before the big reveal. Byvoorbeeld, hier is 'n paar van die bewyse wat in die voorbeeld blog poste getoon word: Chojnowski: Database monitoring grafieke (geschryf per shard), netwerk en skyf prestasie grafieke, CPU statistieke, flame grafieke en instruksies-vlak breek, die CPU se prestasie meet monitoring eenheid (PMU) gebeure, en 'n verskeidenheid van pogings kode regstellings Wenger: Cargo bou timings, 'n tydlijn van kompilasie eenhede, CPU gebruik en concurrent grafieke, debug inligting, flame grafieke, spoor deur Chromium en Perfetto, pogings om kode te herstel, afhanklikheid grafieke Kołaczkowski: 'n blik op die ontwerp van die benchmarking instrument, deurvoer resultate (op sy 4-kern laptop versus 'n 24-kern bediener), flame grafieke Out-of-memory error details, backpressure tests, and multiple forays into memory monitoring Javeria: Gregg: Vlamdiagramme (natuurlik!), ZFS montage besonderhede, arcstats, en al die bron kode, via 'n GitHub skakel die Vlamdiagramme is veral algemeen in bug jag blog poste. Hulle bied 'n goeie manier om jou debugging en prestasie profielproses te visualiseer. En hulle is interaktiewe - gebruikers kan zoom in na die interessante dele, filtreer slegs die gebeure wat ooreenstem met 'n spesifieke gereelde uitdrukking, en nog baie meer. Vlamdiagramme kan geskep word uit die uitvoer van gewilde gereedskap, soos Linux se perf profiel of Rust se vlamdiagram bestelling. 8.4 Expert vriendelik 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. This is distinctly different than in other blog post patterns, such as “We Rewrote It in X” (discussed in Chapter 9). Blog posts in that pattern are more appropriate for those just getting started with the given technology and often include an “Introduction to the New Language” section. 8.4 Opvoedkundige Blog poste volg hierdie patroon kan baie opvoedkundig wees vir ontwikkelaars buite die beïnvloed span. Die vleisige deel, bug identifikasie, is oorvloedig in besonderhede oor hoe om soortgelyke kwessies te inspekteer. Nog belangriker, hierdie afdelings is oorvloedig in herhaalbare besonderhede: diegene wat waarskynlik nuttig sal wees vir die oplos van allerhande soortgelyke probleme wat lesers in die toekoms kan ondervind. Die blogpos dien sy doel as dit die leser uitrust met 'n paar meer truuks wat hulle kan toepas, net in die geval hulle ooit 'n soortgelyke fout op enige punt in hul lewe ontmoet. 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 en Don'ts Die beste blogposte word gebore uit die mees martelende bugjagte. Gedruk deur die glorieuse gevoel om die mysterie uiteindelik op te los, slaan terwyl die yster warm is. Skryf jou indrukke voordat die hoë van die jaag afneem en help jou eweknieë hul volgende geval vinniger op te los. Hier is 'n paar wenke vir die skryf van jou eie Bug Hunt blogpos. 8.5.1 Kyk of iemand (jou baas, jou baas se prokureurs) deur jou deursigtigheid verontrust sal word 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. Before you publish code snippets of your heavily guarded corporate secrets, make sure that your boss and any interested parties are fine with it. Even if you skip the code, your superiors still may be averse to making certain information public, especially if the bug was related to security, or ended with an unfortunate data leak. Use this rule of thumb: Ask first, write and publish later. 8.5.2 Doen 'n tegniese diep duik Tegniese besonderhede is 'n must in enige, nou, blog post. As jou artikel ontbreek besonderhede soos kode monsters, spesifikasies op die presiese tegnologie wat gebruik word, stap-by-stap instruksies, ens, sal baie lesers ontevreden verlaat. Nog erger, hulle kan jou integriteit twyfel. Miskien is die ongemaklike stukke doelbewus verlaat om die produk beter te maak? As jy bekommerd is dat jy te veel tegniese besonderhede kan byvoeg, fout aan die kant van meer. Lesers kan altyd oorskakel as hulle hulle nie interessant vind nie. Tegniese Bug jag blog poste word veral verwag om geladen te word met wenke, truuks, kode, benchmark resultate, sowel as skakels na open-source repositories en dokumentasie. Andersins steel jy lesers die pret geleentheid om hul eie gevolgtrekkings uit die oorvloedige bewyse te trek. Soos voorheen opgemerk, is dit goed om kennersvriendelik hier te wees. Jy kan aanvaar dat die gehoor alreeds vertroud is met die tegnologie wat beskryf word, of bereid is om te vang (met die hulp van jou blogpos). 8.5.3 Be brutally honest about all your failures Jou mislukkings en ellende verskaf lesers met die katartiese effek wat hulle in die eerste plek na jou blogpos gebring het! Hulle gee ook die mees opvoedkundige aspek van bug jag artikels. Die meer pyn en lyding word beskryf in die eerste paragrawe, hoe beter die finale deurbraak lyk. Lesers wat met soortgelyke kwessies sukkel, gaan aktief op die Internet soek na beskrywings van soortgelyke probleme, dus al die hartseer sleutelwoorde soos "gebreek," "fout," of "FUBAR" dien dubbele doeleindes - hulle is 'n emosionele uitlaat vir die skrywer se frustrasie, plus hulle maak ook die blogpos makliker om aanlyn te vind. Moenie probeer om 'n perfekte, onberispelike foutjag te oorleef nie. Dode eindes en mislukte pogings bring tonne opvoedkundige waarde. Programmeurs (wat natuurlik 'n sinoniem is vir "grote gedagtes") dink dieselfde. 8.5.4 Inclusief getalle, benchmarks, metries en vlamdiagramme Benchmark resultate, metrikes, en allerhande getalle is die ekwivalent van wenke en bewyse uit die detektiwiteitswêreld. bug jag blog poste lyk minder wettig as hulle vage frases gebruik soos "ons stelsel is nou baie vinniger." trots op die resultate, dan sou jy hulle geplaas het..." Screenshots van jou metrikes (of selfs beter, interaktiewe figuur soos flame grafieke) vang lesers se oë, maak die artikel beide meer geloofwaardig en meer aangename om te lees. really 8.5.5 Gee nie te veel af nie, te vroeg – hou die spanning gebou Vir die meeste blogposte beveel ons aan om die TL;DR vroeër te deel sodat lesers vinnig kan besluit of hulle wil voortgaan nie. Nie hier nie! Met bughunt blogposte, spoilers te vermy ten alle koste! Die spanning moet geduldig gebou word totdat die aha oomblik plaasvind, en die oplossing geopenbaar word. Dit is die sleutel om lesers (diegene wat nie haastig is nie, ten minste) te toelaat om die opwinding van die jacht, met al sy draai en draai te ervaar. Hulle vermoed reeds dat die artikel met 'n gelukkige einde eindig, want anders sou dit nie gepubliseer word nie. 8.5.6 Moenie ooragtige lesers te hard jaag vir die regstelling nie Dit word gesê, sommige lesers sal ongeduldig raak. Miskien het hulle hul eie gevolgtrekking na net 'n paar paragrawe getrok en wil die onmiddellike bevestiging van die bevestiging dat hulle dit reg gekry het, onmiddellik, in teenstelling met die dwaas ou jy. Miskien is dit die twaalfde Java bug jag blogpos wat hulle hierdie maand gekry het en hulle wil sien of dit nog 'n ander een is waar die vuilverzamelaar uiteindelik moet blameer. Wees vriendelik en merk "die oplossing" met 'n mooi prominente kop so hulle kan vooruit skip na die rookpistool. As 'n bonus, het 'n duidelik gelabelde oplossing is ook nuttig vir diegene wat terugkeer na jou blogpos, want hulle ly nou aan 'n soortgelyke probleem. Terug toe hulle dit vir pret lees, volg hulle sekerlik saam met die opwinding van jou jag. 8.5.7 Voeg breekpunte by waar nodig Bug-jag artikels kan lank word, veral as jy elke klein draai en draai dek (soos jy absoluut moet!) As jy uiteindelik 'n blogpos skryf wat meer as 20 minute of so neem om te lees, oorweeg om 'n paar duidelike breekpunte vir lesers by te voeg, in die geval hulle kies om jou artikel in meer as een sessie te verbruik. U kan byvoorbeeld 'n kort oorsig van die voortgang van die ondersoek tot dusver bied. U kan 'n eksplisiete opmerking byvoeg dat die stappe wat hierbo beskryf is, tot 'n dooie einde gelei het, wat lei tot 'n nuwe stelling. Of u kan eenvoudig subheadings soos "Fase 3" gebruik, wat subliminal aanbeveel dat dit goed is om hier 'n kort koffiepauze te neem sonder om konteks te verloor. 8.5.8 Moenie die lewe daaruit suig nie Lesers is nie hier om 'n amptelike mislukkingsverslag te lees nie. Die fassinerende stukke is die persoonlike storie, die stryd, en die finale vreugde om uit te vind wat verkeerd was. Verhaal dit vanuit jou persoonlike oogpunt. Moenie huiwer om te deel wat deur jou gedagtes gegaan het as die geheim ontvou het nie. Ook, rante is borderline verpligtend en verwag - in redelike dosisse, natuurlik. Diept in, die meeste mense geniet om te lees oor ander mense se frustrasies en voel die indirekte verligting dat dit nie met hulle gebeur het nie (nog). Die "spanning opbou" en "volledige toegang tot wenke verskaf" benaderings wat hierbo gedetailleer is, is twee fundamentele maniere om lesers betrokke te hou (ja, hulle onskuldig gesteel van werklike detektiwiteit stories).Daarbenewens kan jy wil: is 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 Don't forget to thank those who helped along the hunt Die belangrikste rede vir die openbare erkenning van jou medewerkers is suiwer vriendelikheid. Bug jag is een van die mees woedende dele van rekenaarprogrammering, en ellende is lief vir maatskappy. Jou medewerkers het waarskynlik die pyn 'n bietjie minder ontstellend gemaak; as jy dit in elk geval waardeer, dankie hulle hier. Vir die nie-so-empatiese mense, is daar ook pragmatiese (lees: egoïstiese) redes om jou medewerkers te bedank. Jou erkenning kan hulle meer geneig maak om te help in die volgende bug jag. Ook, as jy iemand in 'n blogpos noem, kan jy baie waarborg dat hulle dit sal lees - en miskien sal hulle dit selfs deel. En miskien iemand wat hulle weet, sal die persoon wees om dit te begin op Hacker News. 8.5 Ekstrapolasie 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 Samenvatting Die skryf van 'n bug jag artikel dien om kennis te deel, bewustheid te verhoog oor die bugs wat jy ontmoet het, en jou prestasies te toon. 'N Bug jag blog post is gerig op 'n tegniese gehoor, van kenners tot liefhebbers, gewoonlik aanvaar (ten minste) tussenliggende kennis van die terminologie Bug jag blog poste is gewoonlik swaar op ondersoek besonderhede, toon tegniese bewyse in die vorm van getalle, benchmarks, resultate, en grafieke 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 *** Jy kan meer van die boek voorspel (Moenie die en Let asseblief daarop dat die woorde op 'n oënskynlik willekeurige punt buite ons beheer gekry word. /¯ Op die Manning site foreword by Bryan Cantrill afterword by Scott Hanselman (ツ) die
