Toliau pateiktas įrašas yra išrašas iš 8 skyriaus Rašymas kūrėjams: tinklaraščiai, kuriuos galima perskaityti Piotr Sarna ir Cynthia Dunlop. knyga nagrinėja septynis populiarius inžinerijos dienoraščių modelius: Writing for Developers: Blogs That Get Read Bug medžioklė Mes perrašome jį į X Kaip mes jį pastatėme Pamokos išmoktos Mintys apie tendencijas Ne rinkos produktų perspektyvos Referenciniai rodikliai ir bandymų rezultatai Šaltinis „Bug Hunt“ tinklaraščio įrašo modelis yra programavimo pasaulio ekvivalentas detektyvinės istorijos. Jis turi temą, pagrindinį sklypą, šoninius sklypus, veikėją (jūs), antagonistą (dažniausiai taip pat jūs, pirmą kartą pristatydami klaidą prieš dvi savaites). Tai vilioja, išlaiko skaitytojus susirūpinimą ir baigiasi patenkinamu sklypo posūkiu ar taktiniu kliffhanger. 8.1 Tikslas Rašyti klaidų medžioklės straipsnį tarnauja keliems tikslams, priklausomai nuo medžioklės sėkmės, kur galiausiai nukrito klaida, ir keletas kitų veiksnių. 8.1 Žinių švaistymas Tai, kad klaida pasirodė ir buvo išspręsta, yra neabejotinai svarbu. bet kas yra kur kas svarbiau, tai sumažinti tikimybę, kad tai atsitiks dar kartą – ir žinoti, ką daryti, jei tai atsitiks. A few dead ends Labai įtikinamas raudonasis erelis Įrankis, kuris iš pradžių atrodė naudingas, bet galiausiai buvo nesusijęs Kitas įrankis, kuris pasirodė esąs labai naudingas Some blog post from 2014 that led you to discover the root cause Visi šie žingsniai yra neįtikėtinai naudingi būsimam kitos panašios problemos debuggerui (tikriausiai jūs vėl, du savaites vyresni). Suvokimas apie praeities mirusiuosius galus ir išsiblaškymus yra ypač naudingas čia. Greitas žinomo raudonojo heringo identifikavimas gali sutaupyti būsimam debuggerui (jums) keletą valandų neproduktyvių tyrimų. Galite elgtis su klaidų medžioklės tinklaraščių pranešimais kaip senovinių žinių ritiniais (dvi savaites ar vyresniais), kuriuos sukūrė jūsų pirmtakai (jūs), kad perduotumėte jį ateities kartoms (taip pat jūs). 8.1.2 Global bug awareness It's give-back-to-the-community time! Chances are, the bug that you fixed doesn't uniquely apply to your project. Instead, it was caused by a sneaky pitfall in your language of choice, one of the libraries, or specific hardware. Your article can genuinely inspire others to think "Huh, we do have exactly the same setup – makes me wonder…" It might also motivate the team behind that technology to consider ways to stop others from making the same mistake. As a result, writing a story about how you fixed an interesting bug may cause a few other bugs of the same category to be fixed worldwide. It's a superpower! This purpose is especially important if the bug is related to: „Bloeding Edge“ programinė įranga Novel hardware Jaunoji atviro kodo bendruomenė Jie linkę vystytis dinamiškai ir turi labai mažai bandymų aprėpties, palyginti su pramonės standartais, tiesiog todėl, kad jie yra per jauni, kad būtų įgyvendinti kritinėje projektų masėje. 8.1.3 Sėkmė Tech pasaulio pasigyrimas - tinkamoje dozėje - yra geras jums ir jūsų bendraamžiams. Pasigyrimas dėl kažko įdomaus, pavyzdžiui, medžioklės ir klaidų sprendimo, padeda jums ir jūsų skaitytojams: 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 Auditorija Bug hunting is a technical topic, and the audience for bug hunting blog posts is inherently just as technical. Categories of interested readers include: People with a similar background (which means they are potentially susceptible to introducing or suffering from similar bugs in their systems) Žmonės, kurių darbas yra rasti ir ištaisyti gamybos klaidas Žmonės panašios klaidų medžioklės viduryje Žmonės, kurie gali užkirsti kelią šios klasės klaidų pasikartojimui (tie, kurie yra už technologijos, kurioje atsirado klaida arba dirba su klaidų prevencijos įrankiais) Detektyvinės fantastikos mėgėjai Jūsų kolegos Profesionalūs interneto kritikai, kurie specializuojasi nepageidaujamuose patarimuose Saugu daryti prielaidą, kad žiūrovas yra kažkas, kas: Already has sufficient professional background to understand the technical terms and idioms you use in the article Jei ne, yra pasirengęs juos pažvelgti ir išmokti Jei ne, tai visiškai gerai tik apsimesti, kad jie supranta Todėl gerai traktuoti klaidų medžioklės tinklaraščio įrašą kaip adresuojamą "vidutinio lygio" (arba aukštesnio lygio) skaitytojams, o ne "naujokams". Išplėstiniai techniniai terminai yra gerai, nes nesistengiate, kad straipsnis būtų prieinamas platesnei visuomenei. 8.3 Pavyzdžiai Kadangi klaidos gali atsirasti bet kur, taip pat gali atsirasti klaidų medžioklės tinklaraščių įrašai. Laukinėje gamtoje galite rasti klaidų medžioklės įrašų, paskelbtų įvairiuose tinklaraščiuose: "Big Tech", "Unicorn", "Startup" ir asmeniniai tinklaraščiai. Štai keletas puikių pavyzdžių tinklaraščio įrašų, kurie taiko "Bug Hunt" modelį, kartu su Piotr komentaru apie kiekvieną. 8.3.1 Hunting a NUMA Performance Bug Michał Chojnowski Author: ScyllaDB Blog ( ) Source: https://www.scylladb.com/2021/09/28/hunting-a-numa-performance-bug/ Summary Straipsnyje aprašoma našumo regresija, vykstanti ant šiuolaikinės techninės įrangos su NUMA (nevienodo atminties prieigos) dizainu. Atrodo, kad regresija įvyko atsitiktinai pusėje paleidimų, todėl buvo daug sunkiau nustatyti. Straipsnyje pateikiami keletas nesėkmingų (bet vis dėlto sumanių ir įspūdingų) bandymų diagnozuoti problemą. Commentary Tai yra klaidų medžioklės tinklaraščio įrašų viršūnė. Tai giliai techninė, bet tuo pačiu metu paprasta sekti. Mažiau patyrę skaitytojai gali praleisti kai kurias nitty-gritty detales ir vis dar daug sužinoti. Atsitiktinė patirtis, kurią autorius rodo redaguojant vykdomus dvejetainius failus tiesiogiai, tarsi jie būtų tekstiniai failai, daro tinklaraščio įrašą labai malonus skaityti. 8.3.2 Why Is My Rust Build So Slow? Amos Wenger Author: Vėlyvojo laikotarpio ( Source: https://fasterthanli.me/articles/why-is-my-rust-build-so-slow) Summary Šis išsamus tinklaraščio įrašas tiria Rust projekto sudarymo laiko problemas. Jis parodo keletą metodų, kaip profiliuoti patį kompiliatorių, suskaidyti kompiliacijos procesą į valdomus gabalus ir išmatuoti, kiek laiko užtrunka kiekvienas gabalas ir kodėl. Jis yra pilnas vaizdų, kodo fragmentų ir konkrečių įrankių, kuriuos galite naudoti, aprašymų. Straipsnio išvada iš tikrųjų nėra bet koks vienas proveržis, bet gana sąžiningas patarimas taikyti visus aukščiau išdėstytus metodus, jei nesate patenkinti savo Rust statybos laikais. Commentary Compared to an average technical blog post, this one is a hog – in a purely positive sense! It can easily take a skilled reader half an hour to read through it, and it's probably a good idea to digest it in three or four parts, taking breaks from the screen to avoid dizziness and diplopia. Tai teigiamas bruožas, nes tai daro straipsnį išsiskirti. Daugelis technologijų straipsnių bando išspausti kiek įmanoma daugiau informacijos į 4 iki 6 minučių skaitymo. Ir tai yra teisinga, atsižvelgiant į vidutinį dėmesio trukmę, kurią žmogus kelia išmaniesiems telefonams, o ne žaisti lauke visą dieną su kartais animacinių filmų pertraukomis. Straipsnyje yra unikalus stilius, kuriame yra autoriaus alter ego, "Cool Bear", kuris reguliariai prideda trumpus humoro komentarus - išlaikydamas skaitytoją per (ilgą) skaitymo procesą. Šio tipo klaidų medžioklės tinklaraščio įrašas taip pat tarnauja kaip technikų enciklopedija, skirta „Rust“ kompiliatoriui ištaisyti. Turiu jį pažymėtą, tik tuo atveju, jei kada nors reikia atnaujinti savo žinias apie tai, kaip išmatuoti ryšio laiką mano projektuose. Išvada taip pat yra gana netradicinė: vietoj įtampos kūrimo ir galiausiai pateikiant skaitytojams netikėtą sprendimą, tai tiesiog sąžininga santrauka su paskatinimu pasiekti. Kaip viena kodo eilutė padarė 24 branduolių serverį lėtesnį nei nešiojamas Pjotr Kołaczkowski Author: V. Kęstutis Čiurlionis ( ) Source: https://pkolaczk.github.io/server-slower-than-a-laptop/ Summary The blog post describes how local benchmarks detected a bottleneck on machines with lots of CPU cores. The author shares a performance analysis, performs some profiling, then offers a few explanations of how modern CPUs work under the hood and how the processor caches manage memory. The suggested fix is a natural consequence of the conclusions reached earlier in the article: minimizing the amount of state shared between processor units eliminates the bottleneck. Commentary Jo pavadinimas yra šiek tiek clickbaity, bet vis dar pakankamai elegantiškas, kad būtų išvengta atmetimo vidutinės reklamos blokavimo programinės įrangos. Straipsnis yra slaptas švietimas, skirstantis į tokius dalykus kaip "Kiek nanosekundžių vidutiniškai trunka L3 talpyklos prieiga Intel Xeon." Tai puiki praktika; ji palieka tas detales, atspausdintas skaitytojų protuose be jų suvokimo.Kas žino - galbūt vieną dieną, kad paslėptas patarimas gali padėti išspręsti kito projekto našumo klaidą. 8.3.4 Lessons from Debugging a Tricky Direct Memory Leak „Sanchay Javeria“ Author: „Pinterest“ inžinerijos tinklaraštis ( ) Source: https://medium.com/pinterest-engineering/lessons-from-debugging-a-tricky-direct-memory-leak-f638c722d9f2 Summary "Pinterest" kūrimo komanda dalijasi savo patirtimi ieškodama srauto apdorojimo kodo atminties nutekėjimo, dėl kurio jų paskirstytose sistemose atsirado kaskadinių gedimų. Commentary Tai klasikinis klaidų medžioklės straipsnis – tiek daug, kad jis galėtų būti naudojamas kaip tinklaraščio skelbimo šablonas beveik bet kokiai problemai „Java“ kodo medžioklėje. Jame yra įprasti tyrimo žingsniai, kartu su stebėjimo įrankių ekrano nuotraukomis. Taip pat pagal užsakymą kulminacijos pastraipa vadinama „The Fix“. Tai paaiškina, kad kaltininkas buvo dar viena atminties nutekėjimo problema, kurią netiesiogiai sukėlė šiukšlių surinkimo mechanizmai „Java“. Patarimas: Tai visada yra! In this context, the conclusion isn't really an earth-shattering breakthrough, but it definitely meets the readers' expectations. I bet the majority of the readers think "Ah, I knew it from the start" right after learning the root cause. 8.3.5 ZFS Is Mysteriously Eating My CPU Brendonas Grigelis Author: Brendan Gregg’s Blog ( ) 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 Pats pavadinimas yra viliojantis, bet tada kažkas URL išeina į jus: tai Brendan Gregg, liepsnos grafiko išradėjas! Tai puikus pavyzdys, kodėl asmeninis prekės ženklas yra toks svarbus. Kai matau „Brendan Gregg“, aš iš karto maniau, kad straipsnis yra įdomus ... ir aš neklydau mažiausiai. Given Gregg’s expertise, the problem analysis naturally involved flame graphs. The root cause is quite a surprise, and Gregg described it in a very informal and funny manner. The blog post is also very concise: a three-minute read, even if you reserve some time upfront to look at the flame graph screenshots. It clearly shows that you don't need to write thousands of words to squeeze in lots of knowledge, tips, and interesting technical details. Žiūrėti daugiau naujausių „Bug Hunt“ tinklaraščio įrašų writethat.blog See more recent “Bug Hunt” blog posts Rašyti komentarą.blog Rašyti komentarą.blog 8.4 Savybės Bug Hunt blog posts can vary as wildly as the actual bug hunts – but they tend to share the following characteristics: Jie pasakoja istoriją chronologiškai, nuo to momento, kai blogis atsirado, iki to momento, kai jis buvo paskelbtas mirusiu. Jie daugiausia dėmesio skiria medžioklės jauduliui (ir skausmui). Jie laisvai dalijasi medžioklės metu surinktais įrodymais, kad skaitytojai galėtų dėvėti savo detektyvų skrybėles ir žaisti kartu. Jie daugiausia skirti patyrusiems kūrėjams, kurie žino apie aptariamas technologijas (arba yra pasirengę mokytis, kai jie eina) They offer technical nuggets that could be interesting now, lifesaving later Apsvarstykime kiekvieną iš jų savo ruožtu. 8.4.1 Crafted chronologically Blog'o įrašai dažnai seka konkrečią struktūrą, nes jie yra technologinis ekvivalentas detektyvinėms istorijoms. (Jei norite intro ar atnaujinti detektyvinės istorijos struktūrą, generacinis AI čia atlieka tinkamą darbą). Įvadinė pastraipa neatskleidžia per daug detalių ir tikrai nesuteikia sprendimo. Kai problema yra apibrėžta, medžioklė prasideda, paprastai su keliais nesėkmingais (bet švietimo) bandymais. įtampa didėja, kol autorius pasiekia savo aha momentą, po kurio seka ištaisymo aprašymas (ir tas skyrius paprastai vadinamas "The Fix"). Po sprendimo atskleidimo, tinklaraščio įrašas baigiasi apibūdinant prevencines priemones, kad ši klaida nepasikartotų - ir dažnai glaustas atsiprašymas bet kuriems paveiktiems vartotojams. 8.2 Sunkus medžioklės metu Pavyzdžiui, čia yra tai, kiek laiko kiekvienas iš pirmiau minėtų pavyzdžių dienoraščių praleido tyrime (pagal žodžių skaičių): 85% hunt Chojnowski: 83% hunt Wenger: 83% hunt Kołaczkowski: 82% hunt Javeria: 93% hunt Gregg: 8.4.3 Evidence everywhere 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. Pavyzdžiui, čia yra keletas įrodymų, rodomų pavyzdiniame tinklaraščio įraše: Chojnowski: Duomenų bazės stebėjimo grafikai (rašymai per fragmentą), tinklo ir disko našumo grafikai, CPU statistika, liepsnos grafikai ir instrukcijų lygio gedimai, CPU našumo matavimo stebėjimo vieneto (PMU) įvykiai ir įvairūs bandomi kodo pataisymai Wenger: Krovinių kūrimo tvarkaraščiai, kompiliacijos vienetų laiko juosta, procesoriaus naudojimo ir vienetų grafikai, debug informacija, liepsnos grafikai, Chromium ir Perfetto sekimas, bandomi kodo pataisymai, priklausomybės grafikai Kołaczkowski: Žvilgsnis į lyginamosios analizės įrankio dizainą, perdavimo rezultatai (savo 4 branduolių nešiojamame kompiuteryje prieš 24 branduolių serverį), liepsnos grafikai "Javeria": iš atminties klaidų detalės, atgalinio slėgio testai ir kelios atminties stebėjimo priemonės Gregg: „Flame“ grafikai (žinoma!), ZFS montavimo detalės, arcstats ir visas šaltinio kodas per „GitHub“ nuorodą Šaltinis Flame graphs are particularly common across bug hunting blog posts. They offer a great way to visualize your debugging and performance profiling process. And they’re interactive – users can zoom in to the interesting parts, filter out only the events that match a particular regular expression, and much more. Flame graphs can be created from the output of popular tools, such as Linux's perf profiler or Rust's cargo flame graph command. 8.4 Ekspertų draugiškumas Bug medžioklės straipsniai paprastai yra draugiški ekspertams. Autorius paprastai mano, kad žiūrovai yra kompetentingi (arba bent jau susipažinę) su straipsnyje naudojama technologijų krūva. Kodo pavyzdžiai ir straipsnyje bendrinami scenarijai paprastai yra skirti skaitytojams, kurie yra susipažinę su naudojamomis programavimo kalbomis. Šie pranešimų tipai nėra palankūs pagrindiniams pagrindinių kalbų sąvokų paaiškinimams; jei skaitytojas „neįsivaizduoja“, jiems gali prireikti per jį kariauti arba tiesiog judėti toliau. Tai aiškiai skiriasi nuo kitų tinklaraščio skelbimų modelių, pvz., „Mes persirašėme jį X“ (aptariama 9 skyriuje). tinklaraščio įrašai šiame modelyje labiau tinka tiems, kurie tik pradeda naudotis šia technologija ir dažnai apima skyrių „Įvadas į naują kalbą“. 8.4 Išsilavinimas 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. 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 Dviejų ir tų 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 Patikrinkite, ar kas nors (jūsų bosas, jūsų boso advokatai) bus nusiminęs dėl jūsų skaidrumo 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. Prieš paskelbiant savo griežtai saugomų verslo paslapčių kodų fragmentus, įsitikinkite, kad jūsų viršininkas ir bet kurios suinteresuotosios šalys yra gerai su juo. Net jei praleidžiate kodą, jūsų viršininkai vis dar gali nenorėti atskleisti tam tikros informacijos, ypač jei klaida buvo susijusi su saugumu, arba baigėsi nelaimingu duomenų nutekėjimu. 8.5.2 Do a technical deep dive Techninės detalės yra privaloma bet, gerai, 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. Techninė Ypač tikimasi, kad tinklaraščio įrašai bus pakrauti patarimais, gudrybėmis, kodu, lyginamųjų rezultatų rezultatais, taip pat nuorodomis į atviro kodo saugyklas ir dokumentaciją. Priešingu atveju jūs pavogsite skaitytojams įdomią galimybę padaryti savo išvadas iš gausių įrodymų. Kaip minėta anksčiau, gerai, kad čia būtų ekspertų draugiški. Galite manyti, kad auditorija jau yra susipažinę su aprašyta technologija arba nori sugauti (su savo tinklaraščio įrašo pagalba). 8.5.3 Būkite žiauriai sąžiningi apie visus savo nesėkmes Jūsų nesėkmės ir bėdos suteikia skaitytojams kataraktinį efektą, kuris pirmiausia atnešė juos į jūsų tinklaraščio įrašą! Jie taip pat sukelia labiausiai švietimo aspektą klaidų medžioklės straipsniuose. Blog'o įrašai paprastai parašomi po to, kai buvo nustatyta pagrindinė priežastis ir klaida išspręsta. Kuo daugiau skausmo ir kančių aprašoma pirmosiose pastraipose, tuo geriau atrodo galutinis proveržis. Skaitytojai, kurie kovoja su panašiomis problemomis, aktyviai ieškos interneto panašių problemų aprašymų, todėl visi liūdni raktažodžiai, tokie kaip "pažeistas", "klaida" ar "FUBAR", tarnauja dvejopaisiais tikslais - jie yra emocinis šaltinis autoriaus nusivylimui, be to, jie taip pat palengvina tinklaraščio įrašą rasti internete. Nesistenkite perteikti tobulos, nepriekaištingos klaidų medžioklės. Negyvosios pabaigos ir nesėkmingi bandymai atneša tonų švietimo vertės. Programuotojai (kuris, žinoma, yra sinonimas „dideliems protams“) galvoja vienodai. 8.5.4 Įtraukti skaičiai, lyginamieji rodikliai, metrikos ir liepsnos grafikai Lyginamieji rezultatai, rodikliai ir visų rūšių skaičiai yra lygiaverčiai detektyvinės fantastikos pasaulio patarimams ir įrodymams.Bug medžioklės tinklaraščio įrašai atrodo mažiau teisėti, jei jie naudoja neaiškias frazes, pvz., „mūsų sistema dabar yra daug greitesnė“. Pasididžiaukite rezultatais, tada jūs juos paskelbtumėte..." Screenshots iš jūsų rodiklių (ar dar geriau, interaktyvūs skaičiai, pavyzdžiui, liepsnos grafikai) užfiksuoja skaitytojų akis, todėl straipsnis yra labiau patikimas ir malonus skaityti. Iš tiesų 8.5.5 Neperduokite per daug, per anksti – išlaikykite įtampą 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 Don’t make overeager readers hunt too hard for the fix That being said, some readers will get impatient. Maybe they drew their own conclusion after just a few paragraphs and want the immediate gratification of confirming that they got it right, right away, unlike silly old you. Maybe this is the twelfth Java bug hunting blog post they’ve come across this month and they want to see if this is yet another one where the garbage collector is ultimately to blame. Be kind and mark “the fix” with a nice prominent heading so they can skip ahead to the smoking gun. Kaip premiją, aiškiai pažymėtas sprendimas taip pat yra naudingas tiems, kurie grįžta į jūsų tinklaraščio įrašą, nes jie dabar kenčia nuo panašios problemos. Atgal, kai jie skaitė tai dėl linksmybės, jie tikrai sekė kartu su jūsų medžioklės jauduliu. bet dabar, kai lentelės pasuko, jie nori eiti tiesiai į jūsų sprendimą ir pamatyti, ar tai išgelbės juos savo nuovargio akimirką. 8.5.7 Pridėti pertraukos taškus, kai reikia "Bug hunt" straipsniai gali užtrukti ilgai, ypač jei aptinkate kiekvieną mažą posūkį ir posūkį (kaip jūs tikrai turėtumėte!) Jei galų gale parašysite tinklaraščio įrašą, kuris užtruks daugiau nei 20 minučių, apsvarstykite galimybę pridėti keletą aiškių pertraukų skaitytojams, jei jie nuspręstų vartoti jūsų straipsnį daugiau nei vienoje sesijoje. Pavyzdžiui, galėtumėte pateikti trumpą apžvalgą apie tyrimo pažangą iki šiol. Galėtumėte pridėti aiškią pastabą, kad aukščiau aprašyti žingsniai lėmė mirtiną pabaigą, sukeldami naują tezę. 8.5.8 Negerkite gyvenimo iš jo Skaitytojai nėra čia, kad perskaitytų oficialią nesėkmės ataskaitą. Įspūdingi bitai yra asmeninė istorija, kova ir galutinis džiaugsmas išsiaiškinti, kas buvo neteisinga. Papasakokite apie tai iš savo asmeninio požiūrio. Nedvejodami pasidalinkite tuo, kas vyko per jūsų protą, kai paslaptis atsiskleidė. Be to, rants yra privalomi ir tikimasi - protingomis dozėmis, žinoma. giliai, dauguma žmonių mėgsta skaityti apie kitų žmonių nusivylimus ir jausti netiesioginį palengvėjimą, kad tai jiems neįvyko (dar). The “building tension” and “providing full access to clues” approaches detailed above are two fundamental ways to keep readers engaged (yes, they be gėdos pavogtas iš tikrų detektyvų istorijų). be to, jūs galite norėti: are 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 Svarbiausia priežastis viešai pripažinti savo bendradarbiautojus yra grynas gerumas. Bug medžioklė yra viena iš labiausiai erzinančių kompiuterių programavimo dalių, o nelaimė myli kompaniją. Jūsų bendradarbiai tikriausiai padarė skausmą šiek tiek mažiau skausmingą; jei jūs apskritai tai vertinate, padėkokite jiems čia. Ne taip empatiškiems žmonėms taip pat yra pragmatiškų (skaityti: savanaudiškų) priežasčių padėkoti savo bendradarbiautojams. Jūsų pripažinimas gali padaryti juos labiau tikėtina, kad padėsite kitoje klaidų medžioklėje. Be to, jei pavadinsite ką nors tinklaraštyje, galite gana garantuoti, kad jie jį perskaitys – ir galbūt net pasidalins. Ir gal 8.5 Ekstrapolavimas Nepamirškite ekstrapoliuoti iš konkrečių klaidų (pvz., "Mūsų Rust kodas turėjo klaidą") į daugiau bendrų klausimų (pvz., "Rust standartinė biblioteka leidžia lengvai užblokuoti šiame konkrečiame naudojimo atveju.") Bug medžioklės tinklaraščio įrašai taip pat yra galimybės šviesti šiek tiek šviesos skausmo taškus, kuriuos turite su tam tikra technologija. Jūs sugebėjote pritraukti įkalintą auditoriją, suinteresuotą tuo, ką turite pasakyti. Kodėl gi ne pasinaudoti tuo? Jei pastebėjote kažką ypač problematiško su kalba ar biblioteka, kurią naudojote, įkandykite kulką ir pasiūlykite, kad kažkas turėtų būti išspręsta. Programavimo kalba ir bibliotekos 8.6 Apibendrinimas Rašyti klaidų medžioklės straipsnį padeda dalintis žiniomis, didinti informuotumą apie klaidas, su kuriomis susidūrėte, ir parodyti savo pasiekimus Blog'o įrašas apie klaidų medžioklę skirtas techninei auditorijai, nuo ekspertų iki entuziastų, paprastai darant prielaidą (bent jau) tarpines terminologijos žinias. "Bug hunting" tinklaraščio įrašai paprastai yra sunkūs tyrimo detalėse, pateikiant techninius įrodymus skaičių, lyginamųjų indeksų, rezultatų ir grafikų pavidalu. 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 • • Galite peržiūrėti daugiau knygos (nepraleiskite savo ir Prašome atkreipti dėmesį, kad žodžiai susiduria su kažkokiu, atrodytų, savavališku tašku už mūsų kontrolės ribų. • „Manning“ svetainėje Žymė: Bryan Cantrill Žymė: Scott Hanselman (įskaitant ir Šaltinis
