הבלוג של ינון פרק

זה ייקח רק דקה? באמת?

כולל כתיבת הבדיקה? כולל כתיבת התיעוד לפיצ'ר? כולל הרצת הבדיקות הישנות ותיקון או מחיקה של בדיקות לא רלוונטיות? כולל ניסוח הודעת קומיט טובה? כולל דחיפה לשרת והתמודדות עם קונפליקטים?

תיקונים מהירים ששוברים 50 דברים אחרים לא מוסיפים נקודות לאף אחד. עדיף לקחת אוויר ולכתוב את התיקון בצורה נכונה. החצי שעה שאולי חסכת עכשיו תעלה הרבה יותר בעוד חודשיים.

אז בריאקט עובדים על תיעוד חדש ואחת הדוגמאות שם תפסה את העין של סבסטיאן קרלוס וזכתה לכינוי "התבנית המכוערת ביותר בריאקט". זה הקוד:

function CountLabel({ count }) {
  const [prevCount, setPrevCount] = useState(count);
  const [trend, setTrend] = useState(null);
  if (prevCount !== count) {
    setPrevCount(count);
    setTrend(count > prevCount ? 'increasing' : 'decreasing');
  }
  return (
    <>
      <h1>{count}</h1>
      {trend && <p>The count is {trend}</p>}
    </>
  );
}

הרעיון הוא שהקומפוננטה CountLabel מקבלת את הערך של count מבחוץ וצריכה להציג מגמה - האם הערך הנוכחי גדול או קטן מהערך הקודם. בשביל זה היא שומרת את הערך הקודם ב State ואז אנחנו תקועים וצריכים לעדכן את הסטייט בתוך הקוד הראשי של פונקציית CountLabel. גם בתיעוד של ריאקט מודים שזו לא אופציה טובה, אבל שבמצבים מסוימים היא הדרך היחידה לפתור בעיה.

הקונטקסט לסיפור הזה הוא שעד עכשיו ההמלצה היתה להשתמש ב useEffect כדי לעדכן משתנה סטייט בעקבות שינוי של prop, ועכשיו הם ממליצים לוותר על ה useEffect ולעדכן את הערך ישירות בפונקציה הראשית. האמת היא ששתי האופציות לא טובות, ושתיהן מהוות בסך הכל מעקף עבור ארכיטקטורה גרועה.

פיתרון נכון לשמירת מגמה יהיה לשמור את המגמה יחד עם הסטייט המקורי - כלומר מי שמחזיק את count ואחראי על עדכון שלו הוא גם זה שצריך לשמור את המגמה. שמירת זיכרון של הערך הקודם היא תכונה של הסטייט, בדיוק כמו שמירה של משתנה הסטייט ב Local Storage או כל מניפולציה אחרת על הערך. וכך פיתרון עם Custom Hook הולך להיות הרבה יותר פשוט ויותר נכון מההצעה של סטייט נוסף בקומפוננטת ילד. זה נראה ככה:

import { useState } from "react";

function useTrendedState(initialValue) {
  const [value, setValue] = useState(initialValue);
  const [prevValue, setPrevValue] = useState(initialValue);

  function setter(...args) {
    setPrevValue(value);
    return setValue(...args);
  }

  return [value, setter, prevValue];
}

function CountLabel({ count, prevCount }) {
  let trend;
  if (count < prevCount) {
    trend = "Decreasing";
  } else if (count > prevCount) {
    trend = "Increasing";
  } else {
    trend = "Stable";
  }

  return (
    <>
      <h1>{count}</h1>
      {trend && <p>The count is {trend}</p>}
    </>
  );
}

export default function App() {
  const [count, setCount, prevCount] = useTrendedState(0);
  return (
    <>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <button onClick={() => setCount(count - 1)}>Decrement</button>
      <CountLabel count={count} prevCount={prevCount} />
    </>
  );
}

על הדרך הרווחנו קוד מפורש שמטפל במצב ש count לא השתנה. נכון שבגלל שזה מספרים ובגלל ש useState ממילא לא עושה כלום כשהוא נקרא עם הערך שכבר קיים שם המצב הזה לא אפשרי בקוד הנוכחי, אבל במצבים יותר מורכבים בהחלט אפשר לדמיין משמעות שונה לזהות שכן היתה מייצרת באג בהצעה שבתיעוד (למשל בעבודה עם מערכים או אוביקטים).

כן פתחי מילוט זה חשוב, וכן טוב שיש אותם בפריימוורק, אבל אם כבר בוחרים לתעד פתח מילוט כזה עדיף לבחור דוגמה שבאמת דורשת אותו. ולא, אני לא יכול לחשוב על כזאת דוגמה.

בלימוד נושא חדש, פרסים יכולים להיות דרך קלה להגביר מוטיבציה בנקודות מפתח. לדוגמה-

1. אחרי שאצליח להתמיד שלושה חודשים בספורט אני קונה נעלי ריצה חדשות.

2. כשאסיים לכתוב את האפליקציה הראשונה שלי, אני קונה לעצמי אייפון חדש.

3. כשאסיים להקים מערכת בדיקות אוטומטיות לאתר, אני קונה לעצמי כרטיסים לכנס מקצועי בנושא בדיקות.

הדבר החשוב בשימוש בפרסים הוא לבחור פרסים שיגבירו אצלכם את המוטיבציה ללמוד ויהיו קשורים למיומנות שאתם מנסים לשפר. כך תהיו בטוחים שאחרי הפרס תוכלו להמשיך בתהליך ואף להגביר את הקצב.

בעבודה עם גיט אנחנו אוהבים לבנות כל פיצ'ר בענף משלו ורק אחרי שבדקנו והכל עובד למזג לתוך main (זאת לא הדרך היחידה לעבוד, אבל היא מספיק פופולרית כדי להיחשב למיינסטרים). בעיה שחוזרת לא פעם בשיטת עבודה כזו היא הצורך לבטל מיזוג של ענף, למשל כי אחרי שמיזגנו והעלינו לפרודקשן פתאום גילינו את הבאג ההוא שפספסנו בבדיקות.

חלק מהכיף בלשדרג את כל תשתית האתר הוא לחשוף באגים נסתרים, כלומר באגים שהיו גם בגירסה הקודמת, אבל משום מה בגלל שינויים במקומות אחרים היה קצת יותר קשה לראות אותם. אלה מכם ומכן שרגילים לקרוא את הבלוג דרך האימייל ודאי שמו לב שבשבוע האחרון פוסטים לא הגיעו. ייתכן ובטעות חשבתם שזה בגלל שיצאתי לחופש והרובוט יצא איתי, או שחשבתם שלקחתי גם פסק זמן מפירסום. לצערי הסיבה שונה לגמרי וקשורה לכותרת הפוסט.

אם תקראו את הפוסט הזה מהאתר תראו שמשמאל לפוסט יש תיבת רישום שם אתם יכולים להכניס את כתובת המייל שלכם כדי לקבל פוסטים חדשים ישירות למייל. בגירסה הקודמת של האתר התיבה היתה input מסוג email:

<input type="email" />

אבל בגירסה החדשה (עד אתמול) היא היתה מסוג טקסט:

<input type="text" />

עכשיו תיאורטית זה לא אמור להשפיע על שום דבר - הרי ממילא כל האקר חובב יודע לפתוח את כלי הפיתוח של הדפדפן עם F12 ולשנות את ה type של התיבה. אבל מאיזושהי סיבה כל עוד התיבה היתה מסוג email (וגם קצת אחרי), אף אחד לא ניסה לשלוח בה טקסט חופשי.

עד לפני שבוע בערך.

באותו בוקר מישהו או מישהי שחמדו לצון החליטו לכתוב את הטקסט ״אמא שלך״ בתור כתובת האימייל. לא משהו שהיה אמור לשבור שום דבר, אבל "אמור" זאת לא דרך לכתוב קוד.

מסתבר שספריית mailgun_rails בה אני משתמש כדי לשלוח את המיילים רגישה לכתובות אימייל לא חוקיות. כששלחתי דרכה למיילגאן את רשימת הכתובות להפצה של הפוסט היומי, הקוד התרסק כי "אמא שלך" היא לא כתובת מייל תקנית. הבאג ישן ומפורט בריטהאב כאן: https://github.com/jorgemanrubia/mailgun_rails/issues/48

שלושה לקחים מהסיפור הזה ששווה גם לכם ליישם:

1. כשנתקלים בבאג כזה תמיד יש התלבטות איפה מתקנים אותו, וזה מאוד מפתה לתקן את הבאג בכניסה, כלומר להוסיף וולידציה ולא לשמור כתובת מייל שאינה חוקית בבסיס הנתונים. עשיתי את זה וזה חשוב. אבל התיקון האמיתי הוא להוסיף את הוולידציה ביציאה, כלומר אחרי ששולפים את כל הכתובות מבסיס הנתונים ומכינים את כל המידע למיילגאן, ובדיוק שניה לפני הקריאה לפונקציה ששולחת מייל, יש לסנן החוצה את כל הכתובות הלא חוקיות. בתיאוריה לא אמורות להיות כאלה כי אנחנו חוסמים אותן בכניסה, בפועל כלל אצבע טוב הוא לבצע וולידציה תמיד לפני פעולה מסוכנת (כי אתם לא יודעים אם בעתיד מישהו לא ישנה או יעדכן קוד שישפיע על נתונים שנכנסים למערכת).

2. יש מספיק כלים אוטומטיים שיודעים לשלוח קלט Fuzzy לכל השדות באתר. שימוש בכלי כזה היה מגלה לי את הבאג כבר לפני שנים.

3. הבאג הזה נמצא במערכת מפברואר 2017, ממש מהגירסה הראשונה של מנגנון שליחת הפוסטים במייל. לקח לו כמעט שש שנים להתגלות. כל הזמן הזה המנגנון היה פגיע למתקפות Denial Of Service מאוד פשוטות על מנגנון המיילים (כל מה ש"האקר" היה צריך לעשות זה להירשם עם הכתובת "אמא שלך" לקבלת פוסטים במייל). רק בגלל שקוד עובד לא אומר שהוא נכון.

נ.ב. אתמול אחרי שמצאתי את הבעיה וסידרתי אותה הפוסט נשלח ב-8 עותקים. אני לא יודע אם זה פשוט תוצאה של התקלה שיצרה סוג של פקק במערכת, או שהתיקון שלי יצר באג חדש. אם אתם מקבלים את המייל הזה יותר מפעם אחת קבלו את התנצלותי. אני במקביל ממשיך לעקוב כדי לוודא שהכל חוזר לעבוד כמו שצריך ומודה לכם על הסבלנות.

יש הרבה אנשים שיודעים לדבר בצורה משכנעת, בלי קשר לתוכן הדברים. בתכנות זה לפעמים אפילו יותר קל כי השטן הוא בפרטים ויש המון ניואנסינים קטנים שהמחשב רואה אבל אנחנו מפספסים. תוכנת הבינה המלאכותית החדשה Chat GPT, מעבר לכל היכולות המרשימות שלה, עשויה לסמן נקודת מפנה שבה גם כלים מתחילים לטעות בצורה משכנעת - בדיוק כמונו.

בדוגמה לא טכנית ביקשתי מהחבר לייצר רשימה של מילים בנות 5 אותיות שמתחילות ב e ומכילות j, ככה נראתה השיחה:

Q:
please suggest some 5 letter words that start with an e and contain a j

A:
Here are five 5-letter words that start with an "e" and contain a "j":

    eject - to force out or expel, as by a sudden and vigorous thrust
    jumbo - very large in size or quantity
    jenny - a female donkey or ass
    jewry - the Jewish people or community, especially as a whole
    jowar - a type of sorghum grain that is commonly grown in arid regions of Africa and Asia.

בדוגמה טכנית ביקשתי קוד פייתון שמוריד תמונות בצורה יעילה. קיבלתי תשובה ארוכה שמפספסת את הנקודה. הוא התחיל בשתי דוגמאות קוד שמציגות הורדה של קובץ תמונה עם ספריית requests ועם ספריית urllib, ואז סיים בפיסקה הבאה:

If you want to download multiple images, you can use a loop to iterate over the URLs of the images and download them one at a time using one of the methods described above. You may also want to consider using threading or asyncio to download the images in parallel, which can improve performance if you are downloading a large number of images.

אף מילה על האפשרות להשתמש ב sessions בספריית requests (שברוב המקרים תתן תוצאה טובה יותר משימוש ב Thread-ים או ב async), ובלי הסביר איך לבדוק את הביצועים בעצמך.

צריך להדגיש - אנחנו לא פה בשביל לעשות האנשה לרובוטים. ברור לי איך זה עובד ולמה הטעויות האלה הן חלק אינהרנטי במנגנון. מה שצריך לזכור זה שככל שהשימוש בכלי AI גדל, כך גדל הצורך שלנו להיות ביקורתיים לגבי התוצאות שלהם. יש לנו מנגנונים לסינון תכנים שגויים מויקיפדיה ומ Stack Overflow, ובעתיד נצטרך לייצר מנגנונים דומים כדי להתמודד עם הטעויות והחוסרים בכלי ה AI שיהיו לנו.

בזמן שאתם קוראים את זה אני כבר על המטוס חזרה לארץ. מקווה שנהניתם מהסידרה ובשביל לסיים אותה אני רוצה לראות איך לקרוא קובץ HTML ב Rust ולהדפיס את הכותרות המובילות מאתר Hacker News.

אחרי שכתבנו כלים לשורת הפקודה ואפילו משחק, אנחנו עולים היום לשלב האחרון במדריך ונכנסים לעולם פיתוח ווב עם שרת REST API נוצץ וחלוד.

זוכרים את משחק סנייק מאתמול? אז היום נכתוב ממשק גרפי כדי שנוכל לשחק בו.

ראסט מציע תמיכה מובנית בכתיבת בדיקות יחידה למודולים. בשיעור זה נתחיל לבנות משחק Snake ונראה איך לבדוק את קוד המשחק שלנו לפני שמתחילים לצייר את ה GUI.