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

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

מנגנון Type Hints בפייתון הוא אחד המנגנונים הכי חשובים לבניית קוד קריא וממשק יציב. אבל באותה נשימה צריך גם להגיד שהוא "הולבש" על השפה באיחור, ויהיו מצבים שלמרות כל הרצון הטוב ניתקע ולא נדע איך לכתוב את ה Type Hint הטוב ביותר.

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

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

def random_weighted_item(items):
    items = sorted(items, key=lambda x: x.weight)
    min_weight = min(i.weight for i in items)
    max_weight = max(i.weight for i in items)
    normalized_weights = [(i.weight - min_weight) / (max_weight - min_weight) for i in items]
    cumulative_sum = list(accumulate(normalized_weights))
    randomized_weight = random.random() * cumulative_sum[-1]
    index = next(i for i, e in enumerate(cumulative_sum) if e > randomized_weight)
    return items[index]

אפשר להוסיף לזה בקלות Type Hints בעזרת Type Var וזה יראה כך:

class HasWeight(Protocol):
    weight: int

T = TypeVar("T", bound=HasWeight)

def random_weighted_item(items: list[T]) -> T:
    ...

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

def random_weighted_item(items: list[T], weight: Callable[[T], int]) -> T:
    ...

אבל אז אנחנו רוצים לתמוך גם בהפעלה הקודמת (בלי פונקציית המשקל) ואת זה פייתון כבר לא אוהב:

def random_weighted_item(items: list[T], weight: Callable[[T], int] = lambda i: i.weight) -> T:

הודעת השגיאה היא:

weighted_random_demo.py:44: error: "T" has no attribute "weight"  [attr-defined]
Found 1 error in 1 file (checked 1 source file)

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

1. לבחור חתימה שעובדת יותר טוב עם ה Type Hints (למשל כמו choices שמקבלת רשימה של פריטים ורשימה של משקלים)

2. לוותר על ה Type Hints ולהתעקש על החתימה שבחרנו.

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

נ.ב. אם אתם מכירים פיתרון של Type Hints לחתימה מהדוגמה אשמח לשמוע בתגובות או בטלגרם.

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

אני אוהב איך ש CSS מתפתח ומצליח לפתור את הבעיות תמיד שלוש שנים אחרי הזמן. הסיפור היום הוא על פיצ'ר מ CSS Selectors 4 שנקרא scope שממש הייתי צריך כל החיים אבל בכל מקרה אנחנו לא פה בשביל להתלונן וטוב מאוחר מלעולם לא.

מה ש scope עושה זה נותן לנו להגדיר כללי CSS שמשפיעים רק על אזור מסוים. כלומר אם יש לנו את ה HTML הזה (מתוך הדוגמה ב MDN):

<div class="light-scheme">
  <p>
    MDN contains lots of information about
    <a href="/en-US/docs/Web/HTML">HTML</a>,
    <a href="/en-US/docs/Web/CSS">CSS</a>, and
    <a href="/en-US/docs/Web/JavaScript">JavaScript</a>.
  </p>
</div>

<div class="dark-scheme">
  <p>
    MDN contains lots of information about
    <a href="/en-US/docs/Web/HTML">HTML</a>,
    <a href="/en-US/docs/Web/CSS">CSS</a>, and
    <a href="/en-US/docs/Web/JavaScript">JavaScript</a>.
  </p>
</div>

ואני רוצה לצבוע כל אחד מהדיבים והלינקים שאיתו בצבעים שונים תמיד יכלתי לכתוב CSS בסגנון הזה:

.light-scheme {
  background-color: plum;
}

.light-scheme a {
  color: darkmagenta;
}

.dark-scheme {
    background-color: darkmagenta;
    color: antiquewhite;
}

.dark-scheme a {
  color: plum;
}

די הרבה זמן אני כבר יכול להשתמש ב CSS כזה:

.light-scheme {
  background-color: plum;
  a {
    color: darkmagenta;
  }
}


.dark-scheme {
  background-color: darkmagenta;
  color: antiquewhite;

  a {
    color: plum;
  }
}

ולאחרונה אני יכול להשתמש גם בכתיב הזה כדי להגיע לאותה תוצאה:

@scope (.light-scheme) {
  :scope {
    background-color: plum;
  }

  a {
    color: darkmagenta;
  }
}

@scope (.dark-scheme) {
  :scope {
    background-color: darkmagenta;
    color: antiquewhite;
  }

  a {
    color: plum;
  }
}

ההבדל בין שני האחרונים קשור למשמעות הסמנטית שלהם. האמצעי בעל אותה משמעות כמו הראשון וה Specificity של ההורה נלקח בחשבון כשמחשבים את הערך (צבע במקרה שלנו). ב scope ההורה הוא לא חלק משורת ה Selector ולכן לא נלקח בחשבון בפיתרון קונפליקטים. דוגמה? בטח. ה CSS הזה:

.light-scheme a {
  color: yellow;
}

@scope (.light-scheme) {
  :scope {
    background-color: plum;
  }

  a {
    color: darkmagenta;
  }
}

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

div {
  padding: 10px;
}

.light-scheme a {
  color: yellow;
}

.light-scheme {
  background-color: plum;

  a {
    color: darkmagenta;
  }
}

ייתן ללינקים שבתוך ה light-scheme את הצבע darkmagenta בגלל שהסלקטור שלו יותר ספציפי.

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

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

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

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

הי חברים,

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

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

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

לכן אם אתם-

1. דוברי עברית שרוצים לשפר את האנגלית שלכם, או דוברי אנגלית שרוצים לשפר את הספרדית או הצרפתית שלכם.

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

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

בבקשה השאירו לי הודעה כאן באתר או למייל ynon שטרודל tocode.co.il ואכניס אתכם לקבוצת הניסוי.

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

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

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

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

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

import scala.jdk.CollectionConverters._

val m = Map("a" -> 10)
m.asJava.get("a", 2, 3)

התוצאה היא 0, למרות ש a נמצא במפה. אפשר לטעון ששני הפרמטרים האחרים בלבלו אותו אבל האמת שגם אם נעביר את המחרוזת a לכל הפרמטרים נקבל את אותו 0. הבעיה האמיתית כאן היא ש get של java.util.Map מצפה לקבל פרמטר אחד. העברת יותר פרמטרים לפונקציה היא טעות שהיתה צריכה להתגלות בזמן קומפילציה.

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

val m = Map("a" -> 10)
m.asJava.getOrDefault("a", 1, 2)

-- Error: ----------------------------------------------------------------------
2 |m.asJava.getOrDefault("a", 1, 2)
  |                              ^
  |too many arguments for method getOrDefault in trait Map: (x$0: Object, x$1: V): V
1 error found

אבל כשקומפיילר תופס בעיות רק ב 99% מהמקרים זה לפעמים יותר מתסכל מאשר שלא יתפוס בעיות בכלל.

עוד שבוע מתחיל וסופי שבוע הם זמן מצוין לפתור עוד תרגיל של Advent Of Code. הפעם אנחנו ביום 14 ועדיין עם מטריצות.

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

אבל כל זה היה הגיוני ב 2015. אולי ב 2018.

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

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

להשתמש בסטייט בתור קו מנחה לבחירת קומפוננטות זה קשה כי האינטואיציה שלנו כמתכנתים מחפשת "לסדר" את הקוד לאלמנטים לוגיים. במקרה של ריאקט זה שווה את המאמץ לחשוב כמו מפתחי UI.