Nākamais ieraksts ir izvilkums no 8. nodaļas Rakstīšana izstrādātājiem: Blogi, kurus lasa Piotr Sarna un Cynthia Dunlop. Rakstīšana izstrādātājiem: emuāri, kas tiek lasīti Bug medības Mēs to pārrakstām X Kā mēs to izveidojām Mācīšanās Domas par tendencēm Nekomercializētas produktu perspektīvas Benchmarks un testa rezultāti Tātad “Bug Hunt” emuāra ieraksta modelis ir programmēšanas pasaules ekvivalents detektīvu stāstam. Tam ir tēma, galvenais gabals, sānu gabali, galvenais varonis (jūs), antagonists (parasti arī jūs, pirms divām nedēļām ievadot kļūdu pirmajā vietā). Tas ir aizraujošs, saglabā lasītājus aizkaitināmībā un beidzas ar apmierinošu gabala pagriezienu vai taktisku cliffhanger. 8.1 Mērķis Rakstot bug medību rakstu kalpo vairākiem mērķiem, atkarībā no medības panākumiem, kur kļūda galu galā nokrita, un dažiem citiem faktoriem. 8.1 Zināšanu deficīts Fakts, ka kļūda parādījās un tika novērsta, ir neapšaubāmi svarīgs.Bet tas, kas ir daudz svarīgāk, ir samazināt iespēju, ka tas notiek atkal – un zināt, ko darīt, ja tas notiek. Daži mirušie beidzas Ļoti pārliecinošs sarkans herings Rīks, kas sākotnēji likās noderīgs, bet galu galā nebija saistīts Vēl viens instruments, kas izrādījās ļoti noderīgs Daži emuāru raksti no 2014. gada, kas noveda jūs atklāt saknes cēloni Visi šie soļi ir neticami noderīgi nākotnes debugger par citu līdzīgu problēmu (iespējams, jūs atkal, divas nedēļas vecāks). Apziņa par pagātnes mirušo galu un novirzes ir īpaši noderīga šeit. Ātra identifikācija zināma sarkanā heringa var ietaupīt nākotnes debugger (jūs) dažas stundas neproduktīvu pētījumu. Jūs varat izturēties pret bug medību emuāru kā vecās zināšanas (divas nedēļas vai vecākas), ko izveidojuši jūsu priekšgājēji (jūs), lai nodotu to nākamajām paaudzēm (arī jums). 8.1.2 Globālā bug izpratne Iespējams, kļūda, kuru esat labojis, neattiecas uz jūsu projektu. Tā vietā, tas ir izraisījis traks lamatas jūsu izvēlētajā valodā, vienā no bibliotēkām, vai konkrētu aparatūru. Jūsu raksts var patiesi iedvesmot citus domāt "Huh, mums ir tieši tāda pati uzstādīšana - liek man brīnīties..." Tas varētu arī motivēt komandu aiz šīs tehnoloģijas, lai apsvērt veidus, kā apturēt citus no tā paša kļūda. Tā rezultātā, rakstot stāstu par to, kā jūs labojāt interesantu kļūdu, var izraisīt dažas citas kļūdas no tās pašas kategorijas, kas tiek labotas visā pasaulē. Bloeding Edge programmatūra Hardware jaunumi Jauna atvērtā koda kopiena Tie mēdz attīstīties dinamiski un ir ļoti maz testēšanas seguma salīdzinājumā ar nozares standartiem, vienkārši tāpēc, ka tie ir pārāk jauni, lai tos īstenotu kritiskajā projektu masā. 8.1.3 Brīvības iela Novietojiet malā negatīvo vārda "slavēšana" konotāciju. Tehnoloģiju pasaule - pareizajā devā - ir laba jums un jūsu vienaudžiem. 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 medības ir tehniska tēma, un auditorija bug medības emuāru būtībā ir tikpat tehniski. Cilvēki ar līdzīgu fonu (kas nozīmē, ka viņi ir potenciāli uzņēmīgi ieviest vai cieš no līdzīgiem kļūdām savās sistēmās) Cilvēki, kuru darbs ir atrast un labot ražošanas kļūdas Cilvēki līdzīgas bug medības vidū Cilvēki, kuri varētu izvairīties no šīs kļūdu klases atkārtošanās (tie, kas atrodas aiz tehnoloģijas, kurā notikusi kļūda vai strādā pie defektu novēršanas rīkiem) Detektīvfiksācijas entuziasti Jūsu kolēģi Profesionāli interneta kritiķi, kas specializējas nevēlamos padomos Ir droši pieņemt, ka auditorija ir persona, kas: Jums jau ir pietiekami profesionāla pieredze, lai saprastu tehniskos terminus un idiomas, ko izmantojat rakstā Ja nē, ir gatavs tos apskatīt un mācīties Ja nē, tas ir pilnīgi labi, tikai izlikties, ka viņi to saprot Tāpēc, tas ir labi, lai izturētos pret bug medību emuāru kā vienu, kas adresēta "starpējā līmenī" (vai augstāk) lasītājiem, nevis "jaunpienācējiem." 8.3 Piemēri Tā kā kļūdas var rasties jebkurā vietā, arī var kļūdu medību emuāri. savvaļā jūs varat atrast kļūdu medību emuārus, kas publicēti dažādos emuāros: Big Tech, unicorns, startup un personīgie emuāri. Kopumā, kļūdu medību emuāri, kurus publicējuši lieli augsta profila uzņēmumi, ir pārsteidzoši retāk sastopami (un vairāk aizsargāti) nekā start-up uzņēmumi, kā arī atsevišķi ieguldītāji, kas raksta par atvērtā koda ieguldījumiem un nedēļas nogalēm. 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 veiktspējas bug medības Mihails Čojnovskis Author: Lāčplēša dienasgrāmata ( ) Source: https://www.scylladb.com/2021/09/28/hunting-a-numa-performance-bug/ Summary The article describes a performance regression happening on modern hardware with NUMA (Non-Uniform Memory Access) design. The regression seemed to occur randomly on half of the runs, which made it much harder to pinpoint. The article shares a few failed (but nonetheless skillful and impressive) attempts to diagnose the problem. Then, one of the observations leads straight to a breakthrough and a surprisingly small fix – measured with lines of code. Commentary Tas ir bug medību emuāru virsotne. Tas ir dziļi tehniski, bet tajā pašā laikā ir vienkārši sekot. Mazāk pieredzējuši lasītāji var izlaist dažas no nitty-gritty detaļām un joprojām daudz uzzināt. Visi neveiksmīgie mēģinājumi diagnosticēt problēmu ir izglītojoši un noteikti noderīgi turpmākajā debugging. Gadījuma pieredze, ko autors parāda, rediģējot izpildāmos binārus tieši tā, it kā tie būtu teksta faili, padara emuāra rakstu ļoti patīkamu lasīšanu. 8.3.2 Kāpēc mans Rust veidojas tik lēni? Amoss Vengers Author: Tīmekļa vietne ( Source: https://fasterthanli.me/articles/why-is-my-rust-build-so-slow) Summary Šis plašais emuārs izmeklē kompilācijas laika jautājumus Rust projektam. Tas parāda vairākus paņēmienus, kā profilēt kompilatoru, sadalīt kompilācijas procesu pārvaldāmos gabalos un izmērīt, cik ilgi katrs gabals aizņem un kāpēc. tas ir pilns ar attēliem, koda izvilkumiem un konkrētu rīku aprakstiem, kurus varat izmantot. Raksta secinājums nav patiešām jebkurš atsevišķs sasniegums, bet gan godīgs padoms, kā piemērot visas iepriekš minētās plašās metodes, ja neesat apmierināts ar jūsu Rust veidošanas laiku. Commentary Salīdzinājumā ar vidējo tehnisko emuāru, šis ir hobijs - tīri pozitīvā nozīmē! Tas var viegli aizņemt kvalificētu lasītāju pusstundu, lai to izlasītu, un, iespējams, ir laba ideja to sagremot trīs vai četrās daļās, pārtraucot no ekrāna, lai izvairītos no reibonis un diplopija. Šī ir pozitīva iezīme, jo tas padara rakstu izceļas.Daudzi tehniskie raksti mēģina saspiest pēc iespējas vairāk informācijas 4 līdz 6 minūšu lasīšanas laikā.Un tas ir taisnīgi, ņemot vērā vidējo uzmanības intervālu, ko cilvēks pievērš viedtālruņiem, nevis visu dienu spēlē ārā ar gadījuma karikatūras pārtraukumiem.Tomēr, garš raksts piesauks veco skolu cilvēkus, kuri reiz spēja lasīt grāmatu vienā sēdē. Rakstā ir unikāls stils ar autora alter ego, Cool Bear, kurš regulāri pievieno īsus humora komentārus - saglabājot lasītāju iesaistītu visā (ilgajā) lasīšanas procesā. Tātad Šāda veida bug medību emuāra ieraksts kalpo arī kā enciklopēdija par Rust kompilatoru. Es to iezīmēju, tikai gadījumā, ja man kādreiz ir nepieciešams atsvaidzināt savas zināšanas par to, kā izmērīt saites laiku savos projektos. Secinājums ir arī diezgan netradicionāls: tā vietā, lai veidotu spriedzi un beidzot iepazīstinātu lasītājus ar pārsteidzošu risinājumu, tas ir vienkārši godīgs kopsavilkums ar iedrošinājumu sasniegt. 8.3.3 Kā viena koda līnija padarīja 24 kodolu serveri lēnāku nekā klēpjdators Pjotrs Kołaczkowski Author: Pēteris Kļaviņš ( ) Source: https://pkolaczk.github.io/server-slower-than-a-laptop/ Summary Blog post apraksta, kā vietējie benchmarks atklāja bottleneck mašīnās ar daudziem CPU kodoliem. autors dalās ar veiktspējas analīzi, veic kādu profilēšanu, pēc tam piedāvā dažus paskaidrojumus par to, kā mūsdienu CPU darbojas zem vāka un kā procesora kešatmiņas pārvalda atmiņu. Commentary Tas ir vēl viens zvaigžņu piemērs bug medību blog post. Tās nosaukums ir mazliet clickbaity, bet joprojām pietiekami elegants, lai izvairītos no noraidīšanas ar vidējo reklāmu bloķēšanas programmatūru. Raksts ir slepeni izglītojošs, izklāstot tādas lietas kā "Cik daudz nanosekundes L3 kešatmiņas piekļuve vidēji aizņem Intel Xeon." Tā ir lieliska prakse; tas atstāj šīs detaļas lasītāju prātos bez viņu apzināšanās. kas zina - varbūt kādu dienu, ka slēptais padoms varētu palīdzēt novērst veiktspējas kļūdu citā projektā. 8.3.4 Mācības no Debugging Tricky Direct atmiņas noplūdi Sančē Džavēra Author: Tīmekļa pārlūkprogramma ( ) Source: https://medium.com/pinterest-engineering/lessons-from-debugging-a-tricky-direct-memory-leak-f638c722d9f2 Summary Pinterest izstrādes komanda dalās savā pieredzē, meklējot plūsmas apstrādes koda atmiņas noplūdi, kas izraisīja izkliedētās sistēmas neveiksmes. Commentary Šis ir klasisks kļūdu medību raksts – tik daudz, ka to varētu izmantot kā emuāra veidni, lai medītu gandrīz jebkuru problēmu Java kodā. Tas satur parastos izmeklēšanas soļus, kopā ar ekrānšāviņiem no novērojamības rīkiem. Arī pēc pielāgojuma, kulminācijas punkts tiek saukts par "The Fix." Tas izskaidro, ka vainīgais bija vēl viena atmiņas noplūdes problēma, ko izraisa netieši atkritumu savākšanas mehānismi Java. padoms: Tas vienmēr ir! Šajā kontekstā secinājums patiesībā nav zemes skarbs sasniegums, bet tas noteikti atbilst lasītāju cerībām. es liktu likmi, ka lielākā daļa lasītāju domā "Ah, es to zināju no paša sākuma" tūlīt pēc pamatcēloņa apgūšanas. 8.3.5 ZFS noslēpumaini ēd manu CPU Brendons Gregs Author: Brendan Gregg’s Blog ( ) Source: https://www.brendangregg.com/blog/2021-09-06/zfs-is-mysteriously-eating-my-cpu.html Summary Blog post apraksta medības par iemeslu noslēpumaino augstāku nekā gaidīts CPU izmantošanu.Tā parāda, kā sašaurināt kandidātus uz vienu funkciju zvanu ar analīzes rīkiem un beidzas ar pārsteidzošu veiktspējas kļūdu ZFS - failu sistēmas īstenošanu. Commentary Nosaukums pats par sevi ir aizraujošs, bet tad kaut kas URL nokļūst pie jums: tas ir Brendan Gregg, liesmu grafikas izgudrotājs! Tas ir lielisks piemērs tam, kāpēc personīgais zīmols ir tik svarīgs. Ņemot vērā Gregga pieredzi, problēmu analīze dabiski ietvēra liesmu grafikus. Sakņu cēlonis ir diezgan pārsteidzošs, un Gregg to aprakstīja ļoti neformālā un smieklīgā veidā. Blog post ir arī ļoti īss: trīs minūšu lasīšana, pat ja jūs rezervējat kādu laiku iepriekš, lai apskatītu liesmu grafiku ekrānšāviņus. Tas skaidri parāda, ka jums nav nepieciešams rakstīt tūkstošiem vārdu, lai saspiestu daudz zināšanu, padomu un interesantas tehniskas detaļas. See more recent “Bug Hunt” blog posts Uzrakstīt rakstu.blog See more recent “Bug Hunt” blog posts Uzrakstīt rakstu.blog Uzrakstīt rakstu.blog 8.4 Īpašības Bug Hunt emuāri var atšķirties tikpat savādi kā faktiskās bug medības - bet tie mēdz dalīties šādās īpašībās: Viņi stāsta stāstu hronoloģiski, no brīža, kad ļaunais bug parādījās, līdz brīdim, kad tas tika pasludināts par mirušu Viņi galvenokārt koncentrējas uz aizraušanos (un sāpēm) medībās Viņi brīvi dalās pierādījumos, kas savākti medībās, lai lasītāji varētu valkāt savus detektīvu cepures un spēlēt kopā. Tie lielā mērā ir vērsti uz pieredzējušiem izstrādātājiem, kuri zina apspriestās tehnoloģijas (vai ir gatavi mācīties, kā viņi iet) They offer technical nuggets that could be interesting now, lifesaving later Apskatīsim katru pēc kārtas. 8.1 Krāsošana hronoloģiski Bug hunting blog posts often follow a specific structure since they are the technological equivalent of detective stories. (If you want an intro or refresher on the structure of a detective story, generative AI does a decent job here). The introduction paragraph does not reveal too many details and certainly does not provide a spoiler on the solution. Often, they just elaborate on the (properly mysterious) title with a few more words. Pēc tam, kad problēma ir definēta, medības sākas, parasti ar dažiem neveiksmīgiem (bet izglītojošiem) mēģinājumiem. spriedze veidojas, līdz autors sasniedz savu aha brīdi, kam seko fiksācijas apraksts (un šī sadaļa parasti ir nosaukta "The Fix"). Pēc tam, kad risinājums ir atklāts, emuārs beidzas, aprakstot preventīvus pasākumus, lai novērstu šo kļūdu atkārtošanos - un bieži vien īsu atvainošanos jebkuriem skartiem lietotājiem. 8.2 Smagie medībās Piemēram, šeit ir tas, cik daudz laika katrs no iepriekš minētajiem parauga emuāriem pavadīja izmeklēšanā (pamatojoties uz vārdu skaitu): 85% hunt Chojnowski: 83% hunt Wenger: 83% hunt Kołaczkowski: 82% hunt Javeria: 93% hunt Gregg: 8.3 Pierādījumi visur Bug medību emuāru ieraksti parasti ir pilni ar forenziskiem pierādījumiem. Lasītāji vēlas redzēt liesmu grafikus, skaitļus, diagrammas, skriptus un koda paraugus. Piemēram, šeit ir daži no pierādījumiem, kas parādīti piemērā blog post: Chojnowski: datu bāzes uzraudzības grafiki (rakstījumi par gabalu), tīkla un disku veiktspējas grafiki, CPU statistika, liesmu grafiki un instrukciju līmeņa pārrāvumi, CPU veiktspējas mērīšanas monitoringa vienības (PMU) notikumi un dažādi mēģinājumi labot kodu Wenger: Cargo būvēšanas laiki, kompilācijas vienību laika līnija, CPU izmantošanas un vienlaicīgas grafikas, debug informācija, liesmu grafiki, Chromium un Perfetto izsekošana, mēģinātie koda labojumi, atkarības grafiki A look at the benchmarking tool’s design, throughput results (on his 4-core laptop vs. a 24-core server), flame graphs Kołaczkowski: Javeria: ārpus atmiņas kļūdu detaļas, backpressure testi un vairāki forays atmiņas uzraudzībā Gregg: Flame grafiki (protams!), ZFS montāžas detaļas, arcstats un viss avota kods, izmantojot GitHub saiti Ugunsgrēka grafiki ir īpaši izplatīti visās kļūdu medību emuāru lapās. Tie piedāvā lielisku veidu, kā vizualizēt jūsu debugēšanas un veiktspējas profilēšanas procesu. Un tie ir interaktīvi - lietotāji var palielināt uz interesantajām daļām, filtrēt tikai notikumus, kas atbilst konkrētai regulārai izteiksmei, un daudz ko citu. Ugunsgrēka grafikus var izveidot no populāru rīku, piemēram, Linux profila profila vai Rusta kravas ugunsgrēka grafika komandas, izejas. 8.4 Ekspertu draudzīgs Bug medību raksti parasti ir ekspertu draudzīgi. Autors parasti pieņem, ka auditorijai ir prasme (vai vismaz pazīstama) ar rakstā izmantoto tehnoloģiju kopumu. Koda paraugi un rakstu koplietošana rakstā parasti ir vērsti uz lasītājiem, kuri ir pazīstami ar izmantoto programmēšanas valodu. Šāda veida ieraksti nav labvēlīgi pamata skaidrojumiem par pamatvalodu jēdzieniem; ja lasītājs to nesaņem, viņiem var būt nepieciešams to pārvarēt vai vienkārši turpināt. Tas ir skaidri atšķirīgs no citiem emuāru veidojumiem, piemēram, “Mēs to pārrakstījām X” (apspriests 9. nodaļā). emuāru veidojumi šajā veidnē ir piemērotāki tiem, kas tikko sāka izmantot šo tehnoloģiju, un bieži ietver sadaļu “Ievads jaunajā valodā”. 8.4 Izglītība Blog posts, kas seko šim modelim, var būt diezgan izglītojoši izstrādātājiem ārpus ietekmētās komandas. Gaļas daļa, kļūdu identificēšana, ir bagātīga ar detaļām par to, kā pārbaudīt līdzīgas problēmas. Vēl svarīgāk, šīs sadaļas ir bagātīgas ar atkārtojamām detaļām: tās, kas, visticamāk, būs noderīgas, lai atrisinātu visu veidu līdzīgas problēmas, ar kurām lasītāji varētu saskarties nākotnē. Blog post kalpo savu mērķi, ja tas atstāj lasītāju aprīkot ar dažiem citiem trikiem, kurus viņi var piemērot, tikai gadījumā, ja viņi kādreiz saskaras ar līdzīgu kļūdu kādā brīdī savā dzīvē. Piemēram, šeit ir augsta līmeņa pārskats par to, ko lasītāji varētu uzzināt no katra no mūsu parauga emuāra ierakstiem: 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 and don'ts Labākie emuāru ieraksti ir dzimuši no visvairāk spīdzinošām bug medībām. Vadīts ar slaveno sajūtu, ka beidzot atrisināt noslēpumu, streiki, kamēr dzelzs ir karsts. Rakstīt savus iespaidus, pirms medību augstums nogurst un palīdzēt saviem vienaudžiem atrisināt savu nākamo lietu ātrāk. Šeit ir daži padomi, kā rakstīt savu Bug Hunt emuāru. 8.5.1 Pārbaudiet, vai kāds (jūsu priekšnieks, jūsu priekšnieka advokāti) tiks satraukti par jūsu pārredzamību 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. Pirms jūs publicējat koda fragmentus no jūsu stingri sargātajiem korporatīvajiem noslēpumiem, pārliecinieties, ka jūsu priekšnieks un jebkuras ieinteresētās personas ir labi ar to. pat tad, ja jūs izlaist kodu, jūsu priekšnieki joprojām var būt pret to, lai noteiktu informāciju darītu publisku, it īpaši, ja kļūda bija saistīta ar drošību, vai beidzās ar nelaimīgu datu noplūdi. 8.5.2 Veikt tehnisku dziļu niršanu Tehniskās detaļas ir obligāti jebkurā, labi, Ja jūsu rakstā trūkst detaļu, piemēram, koda paraugu, precīzu izmantoto tehnoloģiju specifikācijas, soli pa solim norādījumus utt., daudzi lasītāji atstās neapmierināti. Vēl sliktāk, viņi var apšaubīt jūsu integritāti. Varbūt nepatīkamie gabali tika apzināti izlaisti, lai produkts izskatītos labāk? Ja jūs uztraucaties, ka jūs varētu pievienot pārāk daudz tehnisko detaļu, kļūda vairāk. Lasītāji vienmēr var izlaist tos, ja viņi tos neuzskata par interesantiem. Tehniskā 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 Esiet brutāli godīgi par visām savām neveiksmēm Jūsu neveiksmes un bēdas sniedz lasītājiem kataraktisko efektu, kas vispirms atnesa tos jūsu emuāram! Tie arī rada visvairāk izglītojošo aspektu no bug medību rakstiem.Galu galā, tas ir lieliski mācīties no kļūdām, bet vēl labāk ir mācīties no kāda cita kļūdām vispirms. 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 Include numbers, benchmarks, metrics, and flame graphs Benchmark rezultāti, rādītāji un visu veidu skaitļi ir līdzvērtīgi padomiem un pierādījumiem no detektīvu fantastikas pasaules. bug medību emuāri izskatās mazāk leģitīmi, ja tie izmanto neskaidras frāzes, piemēram, "mūsu sistēma tagad ir daudz ātrāka." Lasītāji nekavējoties domās "Jā, bet cik ātri?" pēc tam seko "Dārgais autors, ja jūs lepni par rezultātiem, tad jūs būtu publicējuši tos..." Screenshots no jūsu rādītājiem (vai vēl labāk, interaktīvie skaitļi, piemēram, liesmas grafiki) piesaista lasītāju acis, padarot rakstu gan ticamāku, gan patīkamāku lasīt. Patiesībā 8.5.5 Nepalaidiet garām pārāk daudz, pārāk ātri – saglabājiet spriedzes ēku 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 Nelietojiet pārmērīgu lasītāju medības pārāk grūti, lai labotu 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. 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 Pievienojiet pārtraukšanas punktus, ja nepieciešams Bug medību raksti var kļūt garš, it īpaši, ja jūs aptverat katru mazu pagriezienu un pagriezienu (kā jums noteikti vajadzētu!) Ja jūs galu galā rakstāt emuāru, kas aizņems vairāk nekā 20 minūtes, lai lasītu, apsveriet dažus skaidrus pārtraukuma punktus lasītājiem, ja viņi izvēlas patērēt savu rakstu vairāk nekā vienā sesijā. Piemēram, jūs varētu sniegt īsu pārskatu par izmeklēšanas progresu līdz šim. Jūs varētu pievienot skaidru piezīmi, ka iepriekš aprakstītie soļi noveda pie mirušā gala, kas noveda pie jaunas disertācijas. 8.5.8 Nelietojiet sūkāt dzīvi no tā Lasītāji nav šeit, lai izlasītu oficiālu neveiksmes ziņojumu. Aizraujošie gabali ir personīgais stāsts, cīņa un pēdējais prieks noskaidrot, kas bija nepareizi. 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). The “building tension” and “providing full access to clues” approaches detailed above are two fundamental ways to keep readers engaged (yes, they bezkaunīgi nozagti no reāliem detektīvu stāstiem). turklāt jūs varētu vēlēties: ir 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 Vissvarīgākais iemesls, kāpēc jūs publiski atzīstat savus kolēģus, ir tīra laipnība. Bug medības ir viena no dusmīgākajām datoru programmēšanas daļām, un bēdas mīl kompāniju. Jūsu kolēģi, iespējams, padarīja sāpes mazliet mazāk skumjas; ja jūs to vispār novērtējat, paldies viņiem šeit. Ne tik empātiskajiem cilvēkiem, ir arī pragmatiski (lasīt: egoistiski) iemesli pateikties saviem kolēģiem. Jūsu atzīšana varētu padarīt viņus visticamāk palīdzēs nākamajā bug medībās. Arī, ja jūs nosauksiet kādu emuārā, jūs varat diezgan daudz garantēt, ka viņi to izlasīs – un varbūt pat dalīsies ar to. Un varbūt kāds, ko viņi zina, būs persona, kas sāks to 8.5 Ekstrapolācija 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 Summary Rakstot bug medību rakstu kalpo, lai dalītos ar zināšanām, paaugstinātu izpratni par kļūdām, ar kurām esat saskārušies, un parādīt savus sasniegumus Blog post bug medības mērķi tehnisko auditoriju, no ekspertiem entuziastiem, parasti pieņemot (vismaz) starpposma zināšanas par terminoloģiju 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 * ir Jūs varat apskatīt vairāk par grāmatu (Nepalaidiet garām and Lūdzu, ņemiet vērā, ka vārdi kļūst neskaidri kādā šķietami patvaļīgā punktā ārpus mūsu kontroles. • Manning tīmekļa vietne Skatīt: Bryan Cantrill Pēcvārds Scott Hanselman (Šī ir Tātad
