הפוסט הבא הוא תמצית מהפרק 8 של כתיבה למפתחים: בלוגים שקוראים על ידי פיוטר סארנה וסינתה דנלופ. כתיבה למפתחים: בלוגים שקוראים ציד הבוג כותבים את זה ב-X איך נבנה אותו שיעורים למדו מחשבות על מגמות פרספקטיבות מוצר שאינן מסחריות Benchmarks ותוצאות הבדיקה → דפוס הפוסט בבלוג "Bug Hunt" הוא שווה ערך לעולם התכנות של סיפור בלש. יש לו נושא, תולדות עיקריות, תולדות צד, שחקן הראשי (אתה), יריב (בדרך כלל גם אתה, לאחר שהציג את הבגידה לפני שבועיים במקום הראשון). 8.1 מטרה כתיבת מאמר ציד שגיאות משרת כמה מטרות, בהתאם להצלחה של הציד, שבו השגיאה בסופו של דבר נפל, וכמה גורמים אחרים. 8.1 חוסר הידע The fact that a bug appeared and was fixed is undeniably important. But what's way more important is reducing the chance that it happens again – and knowing what to do if it does. While hunting for a bug, it's likely you encountered the following: כמה מתים נגמרים אריה אדום מאוד משכנע כלי שנראה שימושי בהתחלה, אך בסופו של דבר לא קשור כלי נוסף שהוכח שימושי מאוד כמה פוסטים בבלוג משנת 2014 שהובילו אותך לגלות את הסיבה הבסיסית כל השלבים האלה הם שימושיים להפליא עבור הבוגגר העתידי של בעיה דומה אחרת (אולי אתה שוב, שבועיים מבוגר יותר). מודעות של קצות המוות העבר והפריעות הוא שימושי במיוחד כאן. זיהוי מהיר של שרינג אדום ידוע יכול לחסוך את הבוגגר העתידי (אתה) כמה שעות של מחקר לא פרודוקטיבי. אתה יכול לטפל הודעות בלוג ציד שגיאות כמו גלגלי ידע עתיק (שבועיים או יותר), שנוצרו על ידי הקדמונים שלך (אתה) כדי להעביר אותו לדורות הבאים (גם אתה). 8.1.2 מודעות לבלוגים גלובליים הסיכויים הם, הבגידה שפתחת לא חלה באופן ייחודי על הפרויקט שלך. במקום זאת, היא נגרמה על ידי מלכודת מגעילה בשפה שבחרת, באחת הספריות, או בחומרה ספציפית. המאמר שלך יכול באמת לעודד אחרים לחשוב "הואו, יש לנו בדיוק את אותה ההתקנה - זה גורם לי לשאול..." זה יכול גם להניע את הצוות מאחורי הטכנולוגיה הזו לחשוב על דרכים להפסיק אחרים לעשות את אותה טעות. כתוצאה מכך, כתיבת סיפור על איך תיקנת שגיאה מעניינת עלולה לגרום לכמה שגיאות אחרות באותה קטגוריה להיפתר ברחבי העולם. תוכנת Bloeding Edge חדש Hardware קהילת קוד פתוח צעירה אלה נוטים להתפתח באופן דינמי ויש להם כיסוי מבחן קטן מאוד בהשוואה לסטנדרטים בתעשייה פשוט כי הם צעירים מדי כדי להיות מיושם במספר קריטי של פרויקטים. 8.1.3 תזמורת להניח בצד את המשמעות השלילית של המילה "להתגאות". טכנולוגיה בעולם להתגאות - במינון הנכון - הוא טוב לך ואת עמיתיך. להתגאות על לעשות משהו מעניין, כגון ציד ולפתור שגיאה, עוזר לך כמו גם הקוראים שלך: It's educational. Your audience can presumably learn something by reading how you achieved your goal. It broadens your professional network. People intrigued by similar technologies and challenges will likely reach out to you as we outlined in Chapter 1. It feels good. There’s no shame in acknowledging that attention is one of the benefits of telling the world that you did something. It yields free criticism – hopefully constructive criticism, but valuable either way. The (often illusory) sense of anonymity on the Internet makes it easy to criticize others, so you can count on lots of comments and nitpicks after your article goes public. But after filtering out the vitriol, you can often learn something new, or even revisit your whole approach to the problem. 8.2 קהל ציד בוגים הוא נושא טכני, ואת הקהל עבור פוסטים בלוג ציד בוגים הוא באופן טבעי בדיוק כמו טכני. אנשים עם רקע דומה (כלומר הם פוטנציאליים להציג או לסבול מטעמים דומים במערכות שלהם) אנשים שעבודתם היא למצוא ולתקן פגמים בייצור אנשים באמצע ציד בוג דומה אנשים שעלולים להיות מסוגלים למנוע סוג זה של פגמים מתחדשים (אלה מאחורי הטכנולוגיה שבה התרחשה הפגיעה או עובדים על כלים למניעת פגמים) חובבי מחקר פסיכולוגי עמיתיך ביקורת אינטרנט מקצועית המתמחה עצות לא מבוקשות זה בטוח להניח כי הקהל הוא מישהו אשר: כבר יש מספיק רקע מקצועי כדי להבין את המונחים הטכניים ואת האידיוטים שאתה משתמש במאמר אם לא, הוא מוכן להסתכל עליהם וללמוד אם לא, זה בסדר לגמרי רק להעמיד פנים שהם מבינים את זה לכן, זה בסדר להתייחס פוסט בלוג ציד שגיאות כמו אחד מיועד "רמה בינונית" (או מעל) קוראים ולא "חדשים". 8.3 דוגמאות 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. הנה כמה דוגמאות מדהימות של פוסטים בבלוג המייצגים את דפוס "ציד בוג", יחד עם הביקורת של פיוטר על כל אחד מהם. 8.3.1 ציד בוג ביצועים NUMA מיכאל צ'ינוובסקי Author: ג'יימס ג'יימס ( ) Source: https://www.scylladb.com/2021/09/28/hunting-a-numa-performance-bug/ Summary המאמר מתאר רגרסיה של ביצועים המתרחשת על חומרה מודרנית עם עיצוב NUMA (Non-Uniform Memory Access). נראה שהרגרסיה מתרחשת באופן אקראי במחצית מהפעולות, מה שהפך את זה הרבה יותר קשה לזהות. המאמר חולק כמה ניסיונות נכשלים (אבל בכל זאת מיומנים ומרשים) לאבחן את הבעיה. Commentary This is the pinnacle of bug hunting blog posts. It’s deeply technical, but at the same time simple to follow. The less experienced readers can skip some of the nitty-gritty details and still learn a lot. All of the failed attempts to diagnose the issue are educational, and surely usable in future debugging. המומחיות האפשרית שהכותב מראה בעת עריכת בינארי מבוצע ישירות כאילו הם קבצים טקסטים עושה את הפוסט בלוג קריאה נעימה מאוד.הפתרון לבעיה הוא גם מספק מאוד, במיוחד למוחו של מתכנת: רק שורה אחת של קוד חף מפשע השתנה, וכל הגירעונות ביצועים נמחק. 8.3.2 מדוע הרעש שלי בנוי כל כך לאט? אמוס ונגר Author: תגיות קשורות בבלוג ( Source: https://fasterthanli.me/articles/why-is-my-rust-build-so-slow) Summary פוסט בלוג נרחב זה חוקר את בעיות זמן ההרכבה עבור פרויקט Rust. הוא מציג טכניקות רבות כיצד לפרופיל את המחבר עצמו, לפצל את תהליך ההרכבה לחתיכות ניתן לניהול, ולמדוד כמה זמן כל חתיכה לוקח ומדוע. הוא מלא בתמונות, צילומי קוד, תיאורים של כלים מבוססיים אתה יכול להשתמש. Commentary בהשוואה לפוסט בלוג טכני ממוצע, זהו חפץ - במובן חיובי לחלוטין!זה יכול בקלות לקחת קורא מיומן חצי שעה לקרוא אותו, וזה כנראה רעיון טוב לעיכול אותו בשלושה או ארבעה חלקים, לוקח הפסקות מהמסך כדי למנוע סחרחורת ודיפלופיה. 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. במאמר יש סגנון ייחודי המציג את הארגו של המחבר, דוב חם, אשר מוסיף באופן קבוע הערות מצחיקות קצרות - שמירה על הקורא מעורב לאורך תהליך הקריאה (ארוך). → סוג זה של פוסט בלוג ציד שגיאות משמש גם כאנציקלופדיה של טכניקות עבור חיתוך מחבר Rust. יש לי את זה מסומן, רק במקרה שאני צריך לעדכן את הידע שלי על איך למדוד זמן קישור בפרויקטים שלי. 8.3.3 כיצד שורה אחת של קוד עשתה שרת 24 גרם איטי יותר מאשר מחשב נייד פטרו Kołaczkowski Author: פטרוס פרנקלסקי ( ) Source: https://pkolaczk.github.io/server-slower-than-a-laptop/ Summary הפוסט בבלוג מתאר כיצד ביקורות מקומיות זיהו מחסום בבקבוק במכונות עם הרבה ליבות CPU. המחבר חולק ניתוח ביצועים, מבצע פרופיל, ולאחר מכן מציע כמה הסברים על האופן שבו עובדים CPU המודרניים תחת הכובע וכיצד מעבדי ה-Cache מנהלים את הזיכרון. Commentary זהו עוד דוגמה מדהימה של פוסט בלוג ציד שגיאות. הכותרת שלו היא קצת clickbaity, אבל עדיין מספיק אלגנטי כדי למנוע להיות נדחה על ידי התוכנה הממוצעת למניעת פרסומות. המאמר הוא חינוכי לחלוטין, מתמקד בדברים כגון "כמה ננו-שניות לוקח גישה לקאצ'ה L3 בממוצע על Intel Xeon." זה מעשה נהדר; זה משאיר את הפרטים האלה מאוחסנים במוחם של הקוראים מבלי שהם מבינים את זה. 8.3.4 שיעורים מחיקת זיכרון ישיר טריקי סנצ'יי ג'וואריה Author: טכנולוגיית טכנולוגיית טכנולוגיית טכנולוגיה ( ) Source: https://medium.com/pinterest-engineering/lessons-from-debugging-a-tricky-direct-memory-leak-f638c722d9f2 Summary צוות הפיתוח של Pinterest חולק את הניסיון שלהם בחיפוש אחר זיהום קוד עיבוד זרם שהוביל לכישלונות קוסקדיים במערכת הפצה שלהם. Commentary זהו מאמר ציד שגיאות קלאסי – עד כדי כך שהוא יכול לשמש כמודל פוסט בלוג לצוד כמעט כל בעיה בקוד ג'אווה. הוא מכיל את צעדי החקירה הרגילים, יחד עם צילומי מסך מכשירים תצפית. גם בעקבות מותאם אישית, סעיף השיא נקרא "התקן". זה מסביר כי האשם היה עוד בעיה זיכרון זיכרון שנגרם באופן עקיף על ידי מנגנוני איסוף זבל ב ג'אווה. רמז: זה תמיד! 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 ברנדון גרג Author: ג'יימס ג'יימס ( ) Source: https://www.brendangregg.com/blog/2021-09-06/zfs-is-mysteriously-eating-my-cpu.html Summary הפוסט בבלוג מתאר ציד לגורם לשימוש ה-CPU המסתורי גבוה מהצפוי.הוא מראה כיצד לצמצם את המועמדים לביקורת פונקציונלית אחת עם כלים לניתוח ומסתיים באג ביצועים מפתיע ב- ZFS – יישום מערכת קבצים. Commentary הכותרת עצמה מקסימה, אבל אז משהו בכתובת האינטרנט יוצא אליך: זה על ידי ברנדאן גרג, ממציא הגרף האש! זוהי דוגמה מצוינת מדוע המותג האישי חשוב כל כך הרבה. בהתחשב במומחיותו של גרג, ניתוח הבעיה הכרוך באופן טבעי בגרפים של אש. הסיבה השורשית היא די מפתיעה, וגרג תיאר את זה בצורה מאוד לא רשמית ומצחיקה. הפוסט בבלוג הוא גם מאוד קצר: קריאה של שלוש דקות, גם אם אתה שומר קצת זמן מראש כדי להסתכל על צילומי מסך של גרפים של אש. זה מראה בבירור שאתה לא צריך לכתוב אלפי מילים כדי לדחוף הרבה ידע, טיפים ופרטים טכניים מעניינים. ראה הודעות הבלוג האחרונות של "Bug Hunt" ב writethat.blog See more recent “Bug Hunt” blog posts לכתוב על: Blog לכתוב על: Blog 8.4 מאפיינים פוסטים בבלוג של Bug Hunt יכולים להשתנות באותה מידה כמו ציד הבגידים בפועל - אבל הם נוטים לשתף את המאפיינים הבאים: הם מספרים את הסיפור באופן כרונולוגי, מרגע שהדבר הרע התבטא, עד שהוכרז שהוא מת. הם מתמקדים בעיקר בהתרגשות (ואף בכאב) של הציד הם חולקים באופן חופשי את הראיות שנאספו לאורך הציד כדי שהקוראים יוכלו ללבוש את כובעי הבלש שלהם ולשחק יחד. הם מיועדים בעיקר למפתחים מנוסים שיודעים את הטכנולוגיות המוזכרות (או מוכנים ללמוד ככל שהם הולכים) הם מציעים ניג'טים טכניים שיכולים להיות מעניינים עכשיו, להציל חיים מאוחר יותר בואו נסתכל על כל אחת בתור. 8.1 כרונולוגית פוסטים בבלוג לעתים קרובות לעקוב אחר מבנה מסוים כי הם שווה ערך טכנולוגי של סיפורי בלש. (אם אתה רוצה מבוא או חידוש על המבנה של סיפור בלש, AI גנרטור עושה עבודה ראויה כאן). לאחר שהבעיה מוגדרת, ההרפתקה מתחילה, בדרך כלל עם כמה ניסיונות נכשלים (אבל חינוכיים).המתח מתבצע עד שהכותב מגיע לרגע ה- aha שלהם, ואחריו תיאור התיקון (והחלק הזה נקרא בדרך כלל "התיקון"). 8.2 כבד על הציד הוצאת כ-80% מהפוסט להסביר את תהליך החקירה היא כלל טוב.לדוגמה, הנה כמה זמן כל אחד מהפוסטים בבלוג הדוגמא לעיל בילה בחקירה (בהתבסס על מספר המילים): 85% hunt Chojnowski: 83% hunt Wenger: 83% hunt Kołaczkowski: 82% hunt Javeria: 93% hunt Gregg: 8.4.3 Evidence everywhere פוסטים בבלוג הם בדרך כלל מלאי ראיות משפטיות. הקוראים רוצים לראות גרפיקות אש, מספרים, תרשימים, סקריפטים ודוגמאות של קוד. זה מאפשר להם ללכת לתוך נעלי הבלש שלך ולנסות להבין את התעלומה לפני התגלות גדולה. לדוגמה, הנה כמה מההוכחות המוצגות בפוסטים בבלוג לדוגמה: צ'ינוובסקי: תרשימי מעקב מסד נתונים (כתובים על בסיס), תרשימי ביצועים של רשת ודיסק, סטטיסטיקות CPU, תרשימי אש והפרעות ברמה של הוראות, אירועים של יחידת מעקב המדידה ביצועים של CPU (PMU) ומגוון של תיקונים של קוד מנסים ונגר: לוח זמנים של Cargo build, לוח זמנים של יחידות compilation, תרשימים של שימוש ב-CPU ותקופות תואמות, מידע חיתוך, תרשימים של אש, מעקב דרך Chromium ו- Perfetto, תיקוני קוד ניסו, תרשימים של תלות קולהסקובסקי: מבט על העיצוב של כלי ההשוואה, תוצאות הפצה (על המחשב הנייד הרביעי שלו לעומת שרת ה-24 ליבה), גרפיקות אש Out-of-memory error details, backpressure tests, and multiple forays into memory monitoring Javeria: גרג: גרפים של אש (אבל כמובן!), פרטים על ההרכבה של ZFS, arcstats וכל קוד המקור, באמצעות קישור GitHub → גרפי Flames נפוצים במיוחד בפוסטים בבלוג.הם מציעים דרך מצוינת כדי להציג את תהליך הבועה והפרופיל הביצועים שלך.הם אינטראקטיביים - משתמשים יכולים להגדיל לחלקים מעניינים, לסנן רק את האירועים המתאימים ביטוי קבוע מסוים, ועוד הרבה יותר.גרפי Flames ניתן ליצור מהיציאה של כלים פופולריים, כגון פרופיל פרופ' של לינוקס או פקודת גרפי Flames של Rust. 8.4.4 Expert friendly מאמרים ציד שגיאות נוטים להיות ידידותיים למומחים. המחבר בדרך כלל מניח כי הקהל הוא מוכשר (או לפחות מוכר) עם המערך הטכנולוגי המשמש במאמר. דוגמאות קוד וסקריפטים משותפים במאמר בדרך כלל מיועדים לקוראים המוכרים בשפות התכנות המשמשות. זה שונה בבירור מאשר בדפוסים אחרים של פוסטים בלוג, כגון "אנחנו כותבים אותו מחדש ב- X" (דיון בפרק 9). 8.4.5 Educational פוסטים בלוגים בעקבות דפוס זה יכולים להיות די חינוכיים עבור מפתחים מעבר לקבוצה המושפעת. החלק הבשרני, זיהוי שגיאות, הוא עשיר בפרטים על איך לבדוק בעיות דומות. עוד יותר חשוב, סעיפים אלה עשירים בפירוט חוזר: אלה שיכולים להיות שימושיים לפתור כל מיני בעיות דומות כי קוראים עשויים להתמודד בעתיד. הפוסט הבלוג משרת את מטרתו אם הוא משאיר את הקורא מצויד עם עוד כמה טריקים שהם יכולים ליישם, רק במקרה שהם נתקלים באותו שגיאה בשלב כלשהו בחייהם. לדוגמה, הנה תצוגה ברמה גבוהה של מה הקוראים יכולים ללמוד מכל פוסט דוגמא שלנו: 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 Do'ts ו 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 Check if anyone (your boss, your boss's lawyers) will be upset by your transparency זה חשוב במיוחד אם אתם רודפים אחרי שגיאה שהשפיעה באופן משמעותי על המשתמשים – או אם גילוי שגיאה זו עלול להשפיע לרעה על המוניטין של החברה שלכם ו/או על מחירי המניות החשובים ביותר. 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 לעשות צלילה טכנית עמוקה 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 פוסטים בבלוג צייד שגיאות צפויים במיוחד להיות עמוסים עם טיפים, טריקים, קוד, תוצאות התייחסות, כמו גם קישורים לאחסונים מקוריים ומסמכים. אחרת, אתה גונב קוראים את ההזדמנות הכי כיפית כדי להסיק מסקנות משלהם מהראיות המרובות. כפי שצוין קודם לכן, זה בסדר להיות ידידותי למומחים כאן. אתה יכול להניח כי הקהל כבר מכיר את הטכנולוגיה המתוארת, או מוכן לתפוס (באמצעות פוסט הבלוג שלך). 8.5.3 להיות אכזרי כנה על כל הכישלונות שלך הכישלונות והסבל שלך מספקים לקוראים את ההשפעה הקתארטית שהביאה אותם לפוסט הבלוג שלך במקום הראשון! הם גם יוצרים את ההיבט החינוכי ביותר של מאמרים ציד שגיאות. אחרי הכל, זה נהדר ללמוד מטעויות, אבל זה אפילו טוב יותר ללמוד מטעויות של מישהו אחר קודם. הפוסטים בבלוג נכתבים בדרך כלל לאחר שהסיבה הבסיסית נזכרת והשגיאה נפתרה. ככל שהכאב והסבל מתוארים בפרקים הראשונים, כך נראה ההישג הסופי טוב יותר. הקוראים המתמודדים עם בעיות דומות הולכים לחפש באופן פעיל באינטרנט תיאורים של בעיות דומות, כך שכל מילות המפתח הכואבות כמו "שבור", "אשמה" או "FUBAR" משמשות למטרות כפולות - הם פלט רגשי עבור התסכול של המחבר, בנוסף הם גם עושים את הפוסט בבלוג קל יותר למצוא באינטרנט. אל תנסו להעביר ציד שגיאות מושלם, לא מקורי. קצוות מתים וניסיונות לא מוצלחים מביאים טונות של ערך חינוכי. מתכנתים (שהוא כמובן סינכרון ל"מוחות גדולים") חושבים באותו אופן. 8.5.4 כולל מספרים, מדדים, מטריקים וגרפיקות אש תוצאות מדד, מדדים, וסוגים שונים של מספרים הם שווה ערך לסימנים והוכחות מהעולם של בדיוני בלוג. הפוסטים בבלוג נראים פחות חוקיים אם הם משתמשים בביטויים מעורפלים כגון "המערכת שלנו היא עכשיו הרבה יותר מהירה." 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. באמת 8.5.5 אל תוותרו יותר מדי, מוקדם מדי – שמרו על בניית המתח עבור רוב הפוסטים בבלוג, אנו ממליצים לשתף את TL;DR מוקדם כך הקוראים יכולים להחליט במהירות אם הם רוצים להמשיך. לא כאן! עם הודעות בלוג ציד בוגים, להימנע ספוילרים בכל מחיר! המתח צריך להיות בנוי בסבלנות עד הרגע האהה מתרחש, ואת התיקון נחשף. זה הוא המפתח לאפשר לקוראים (אלה לא בהמה, לפחות) לחוות את ההתרגשות של ציד בוגים, עם כל הסיבובים והסיבובים שלה. הם כנראה כבר חושדים כי המאמר מסתיים עם סוף מאושר, כי אחרת זה לא יהיה פורסם. 8.5.6 לא לגרום לקוראים overereager לרדוף קשה מדי עבור התיקון עם זאת, כמה קוראים יהיו חסרי סבלנות. אולי הם הוציאו את המסקנה שלהם לאחר כמה סעיפים ורוצים את שביעות רצון מיידית של אישור כי הם קיבלו את זה נכון, מיד, שלא כמו אתה מטומטם זקן. אולי זהו פוסט הבלוג של ג'אווה גולש שגיאות ה-12 הם נתקלו בחודש זה והם רוצים לראות אם זה עוד אחד שבו אוסף הזבל הוא בסופו של דבר להאשים. להיות נחמד ולציין את "התקן" עם כותרת מפורטת נחמדה כך שהם יכולים לקפוץ קדימה לרובה. כמו בונוס, שיש תיקון מסומן בבירור הוא גם שימושי לאלה שמחזירים את הפוסט שלך בלוג כי הם כעת סובלים מבעיה דומה.חזרה כאשר הם קראו את זה בשביל הכיף, הם בהחלט עקבו יחד עם ההתרגשות של הציד שלך.אבל עכשיו כי השולחנות הפכו, הם רוצים ללכת ישירות לתקן ולראות אם זה ישמור אותם ברגע שלהם של ייאוש. 8.5.7 הוסף נקודות פריצה כאשר יש צורך מאמרים ציד שגיאות יכול להיות ארוך, במיוחד אם אתה מכסה כל סיבוב קטן והפוך (כפי שאתה בהחלט צריך!) אם אתה בסופו של דבר לכתוב פוסט בלוג זה ייקח יותר מ 20 דקות או כך לקרוא, לשקול להוסיף כמה נקודות פריצה ברורות לקוראים, במקרה שהם בוחרים לצרוך את המאמר שלך יותר מפעם אחת. For example, you could provide a short recap of the progress of the investigation so far. You might add an explicit note that the steps described above led to a dead end, leading to a new thesis. Or you could simply use subheadings like “Phase 3,” subliminally suggesting to the reader that it's fine to take a short coffee break here without losing context. 8.5.8 Don't suck the life out of it הקוראים אינם כאן כדי לקרוא דו"ח כישלון רשמי. החלקים המרתקים הם הסיפור האישי, המאבק, והאושר הסופי של מגלה מה לא בסדר. 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). הגישות "בניית מתח" ו"ספק גישה מלאה לרמזים" המפורטים לעיל הן שתי דרכים בסיסיות לשמור על הקוראים מעורבים (כן, הם shamelessly stolen from real detective stories). In addition, you might want to: הם 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 הסיבה החשובה ביותר להכרה פומבית של העוזרים שלך היא ידידות טהורה. ציד בוגים הוא בין החלקים הכועסים ביותר של תכנות מחשב, וסבל אוהב חברה. העוזרים שלך כנראה עשו את הכאב קצת פחות מכאיב; אם אתה מעריך את זה בכלל, להודות להם כאן. עבור האנשים לא כל כך אמפתי, יש גם סיבות פרגמטיות (קרא: אנוכי) להודות לעובדים שלך. ההכרה שלך עשויה להפוך אותם סביר יותר לסייע בחיפוש בוגים הבא. כמו כן, אם אתה שם מישהו בפוסט בבלוג, אתה יכול להבטיח די הרבה שהם יקראו את זה - ואולי הם אפילו ישתפו אותו. ואולי מישהו שהם יודעים יהיה האדם שיתחיל את המגמה על חדשות האקר. 8.5 חריג תרגיש חופשי לחלץ מטעויות ספציפיות (לדוגמה, "קוד Rust שלנו היה שגיאה") לתוך נושאים כלליים יותר (לדוגמה, "ספריה סטנדרטית של Rust עושה את זה קל לתפוס במקרה של שימוש ספציפי זה.") הודעות בלוג ציד שגיאות הן גם הזדמנויות להדליק קצת אור על נקודות הכאב שיש לך עם טכנולוגיה מסוימת. הצלחת למשוך קהל אובססיבי, מעוניין במה שיש לך לומר. למה לא לנצל את זה? אם אתה מציין משהו בעייתי במיוחד עם השפה או הספריה שאתה משתמש, לטעום את הכדור ולהציע כי משהו צריך להיות מתוקן למעלה. 8.6 סיכום כתיבת מאמר ציד שגיאות משמשת לשתף ידע, להעלות את המודעות על שגיאות פגשת, ולהציג את ההישגים שלך פוסט בלוג צייד שגיאות מכוון לקהל טכני, מ מומחים לאוהדים, בדרך כלל בהנחה (לפחות) ידע בינוני של המונח. פוסטים בבלוג הם בדרך כלל כבד על פרטים חקירה, מציג ראיות טכניות בצורה של מספרים, מדדים, תוצאות, גרפים 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 * *עריכה אתה יכול להציג עוד מהספר (אל תפספסו את ו אנא שימו לב שהמילים מתבלבלות בנקודה כלשהי שנראית לי סבירה מחוץ לשליטתנו. /¯ on the Manning site תגית: Bryan Cantrill תגית: Scott Hanselman (תא)
