ToCode

# לא למבחן ״מה עדיף, לעשות שיעורי בית או להצליח במבחן?״ השאלה הזאת יכולה לנקז את כל הטעויות של מערכת החינוך ובמשפט אחד. כי ברור שהמטרה של בתי ספר וגם אוניברסיטאות היא שתעברו את המבחן; ברור ששיעורי הבית הם שם בשביל לעזור לכם להצליח במבחן, אבל לא כולם "צריכים" אותם, וברור שאף אחד לא יבלבל את המוח לתלמיד שמקבל מאיות בכל המבחנים גם אם הוא לא מכין שיעורי בית. אבל כשמסתכלים על החיים ומה חשוב קל לראות שהמטרה הפוכה: 1. אף אחד לא יודע מראש לאן כדאי להגיע ואיזו רמת מיומנות נצטרך. 2. לאנשים שונים יש מטרות שונות. 3. אנחנו מבלים הרבה יותר זמן ב"שיעורי בית" מאשר ב"מבחנים". 4. ברוב המקרים ל"כישלון" או"הצלחה" ברגע אחד של מבחן אין השפעה דרמטית על החיים שלנו. אם נפתח את זה לדוגמה של בן אדם שרוצה להתקבל לעבודה חדשה, קל לראות איך בוגר מערכת החינוך יסתכל על המשימה - ראיון עבודה הוא ה"מבחן", לפני הראיון כדאי לשבת ולהתכונן כמה ימים (או שבועות) בבית, והצלחה או כישלון בראיון הם בעלי פוטנציאל לשנות דרמטית את החיים שלי, כי אולי אגיע לעבודה יותר מעניינת או עם יותר כסף. או בדוגמה נוספת מתכנתת שמנסה לקבל השקעה לסטארט-אפ שהיא רוצה להקים עשויה להסתכל על הפגישה עם המשקיע כמו מבחן, ולהעביר את הימים או שבועות לפני הפגישה בלי שינה ובתיקוני באגים ב MVP כדי להגיע כמה שיותר מוכנה לדמו. אבל תפיסת עולם שמתמקדת בשיעורי הבית היתה מובילה אותנו להתנהלות אחרת לגמרי, ולדעתי יותר בריאה: המתכנת שלא מרוצה מהעבודה שלו ירוויח אם הוא יתחיל עוד היום ללמוד טכנולוגיות חדשות ולהשקיע יותר זמן בתוך יום העבודה בשילוב אותן טכנולוגיות, אם באמצעות הכנסת פרויקטים חדשים לארגון, באמצעות אירגון הרצאות העשרה, או בכתיבת פרויקטי צד. מתכנתים שכבר לוקחים חלק בפיתוח בטכנולוגיות חדשות או פעילים בפרויקטי קוד פתוח מוצאים יותר בקלות הזדמנויות וגם כשמגיעים לראיון הם כבר יכולים לספר על כל העבודה שהם עשו על פרויקטים דומים בעבר. הצלחה או כישלון בראיון עבודה כמעט לא ישפיעו על החיים של אותו מתכנת, שימשיך לעבוד בטכנולוגיה שהוא בוחר בכל מקום בו הוא נמצא. והמתכנתת שרוצה לבנות סטארט-אפ יכולה לבחור בכיוון של בוטסטרפ ולבנות מוצר שמהיום הראשון אנשים ירצו לשלם עליו. ככל שלחברה יהיו יותר הכנסות השיחה עם המשקיעים מקבלת אופי אחר ולהצלחה או כישלון בגיוס השקעה לא תהיה השפעה דרמטית על עתיד הפרויקט. ההתנהגות והבחירות שלנו מושפעות מתפיסת העולם שלנו כלומר מאיך שאנחנו חושבים שהעולם עובד. כשאנחנו בטוחים ש"כל דבר הוא מבחן" אנחנו נחפש את המבחנים האלה וננווט לתוך דרכים שבהן באמת כל דבר הוא מבחן. יש אנשים שאוהבים את השיטה הזאת ואם היא מתאימה לכם הרווחתם, אבל שווה לזכור שהיא לא היחידה ואם היא לא מתאימה לכם אפשר להתאמץ ולהחליף.

# שיתוף תוכן ב Mobile Web לא מזמן פרסמו ב Smashing רשימה של Web APIs פחות מוכרים, וביניהם גיליתי את האוצר עליו אספר לכם בפוסט הזה. ## מה זה שיתוף תוכן גם אנדרואיד וגם אייפון מכילים תמיכה מובנית בדיאלוג שיתוף - משתמש לוחץ על כפתור באיזושהי אפליקציה, ואז מערכת ההפעלה של הטלפון מראה רשימה של אפליקציות שדרכן אפשר לשתף את התוכן. בדרך כלל זה יהיה "שמירה לפתקים", "יצירת דואר אלקטרוני", "שמירה למסמכים" וכמובן שיתוף דרך אפליקציות המסרים. גם על מחשבי Desktop יש מנגנון דומה, למרות שהוא פחות מוכר והרבה פחות נתמך. ה Web API של שיתוף תוכן פשוט מאפשר לנו להשתמש באותו דיאלוג שיתוף גם מתוך אפליקציית ווב או אתר מותאם. בין הדוגמאות הטובות לשימוש במנגנון אפשר למצוא - שיתוף פוסטים בבלוג (כפתור שייכנס בגירסה החדשה של הבלוג הזה), שיתוף כרטיס מידע, שיתוף איש קשר, שיתוף משימה, שיתוף מסמך ומקרים דומים נוספים. ## איך זה עובד שתי הפונקציות היחידות ש API הן: 1. navigator.canShare() שמחזירה האם הדפדפן תומך בשיתוף המידע מהסוג שרציתם 2. navigator.share() שפותחת את דיאלוג השיתוף קוד? ברור. הנה הגירסה המוטמעת בקודפן: <iframe height="300" style="width: 100%;" scrolling="no" title="Untitled" src="https://codepen.io/ynonp/embed/WNJpaxw?default-tab=html%2Cresult" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true"> See the Pen <a href="https://codepen.io/ynonp/pen/WNJpaxw"> Untitled</a> by Ynon Perek (<a href="https://codepen.io/ynonp">@ynonp</a>) on <a href="https://codepen.io">CodePen</a>. </iframe> והקוד עצמו הוא בסך הכל:

const share = async (shareData) => {
  try {
    await navigator.share(shareData);
  } catch (error) {
    console.error(error);
  }
};

const shareButton = document.querySelector("#share-button");

shareButton.addEventListener("click", () => {
    let shareData = {
      title: "you rock",
      text: "Visit https://www.tocode.co.il to find great programming resources"
    };

    share(shareData);
});

## מגבלות ל API יש מספר מגבלות שכדאי להכיר: 1. אפשר להפעיל את הפונקציה share רק בתגובה לאירוע שיזם המשתמש - לדוגמה לחיצה על כפתור. 2. אפשר לשתף רק מתוך אתרי https. 3. תמיכת דפדפנים יחסית מוגבלת. זה עובד טוב במובייל, כרום על חלונות וספארי במק. האוביקט עצמו שמשתפים כולל 4 סוגי מידע שאפשר לשתף: url, text, title ו files. לא חייבים להעביר את כולם ובדוגמה שלי העברתי רק title ו text.

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

const square = [10, 5, 2, 'red'];

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

type User = [number, string, string];

const users: Array<User> = [
    [0, 'a@gmail.com', 'a'],
    [1, 'b@gmail.com', 'b'],
    [2, 'c@gmail.com', 'c'],
];

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

type User = [number, string, string];

const users: Array<User> = [
    [0, 'a@gmail.com', 'a'],
    [1, 'b@gmail.com', 'b'],
    [2, 'c@gmail.com', 'c'],
];

users.push(['d']);

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

type User = [number, string, string];

const users: Array<User> = [
    [0, 'a@gmail.com', 'a'],
    [1, 'b@gmail.com', 'b'],
    [2, 'c@gmail.com', 'c'],
];

const u: User = [3, 'd@gmail.com', 'd'];
u.splice(0, 2);
// u is now: ['d']
users.push(u);

שווה לשים לב שכשמשתמשים ב Tuples כדאי תמיד להוסיף להם Readonly כדי שמשתמשים לא יוכלו (בכוונה או בטעות) לרמות. ככה זה נראה כשה Tuple לקריאה בלבד:

type User = Readonly<[number, string, string]>;

const users: Array<User> = [
    [0, 'a@gmail.com', 'a'],
    [1, 'b@gmail.com', 'b'],
    [2, 'c@gmail.com', 'c'],
];

const u: User = [3, 'd@gmail.com', 'd'];
u.splice(0, 2);

ועכשיו הקוד שוב לא מתקמפל וטייפסקריפט כותב על השורה האחרונה:

Property 'splice' does not exist on type 'readonly [number, string, string]'. Did you mean 'slice'?

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

/a/b/c/1/x.pl
/a/b/c/d/e/2/x.pl
/a/b/c/d/3/x.pl
/a/b/c/4/x.pl
/a/b/c/d/5/x.pl

נצטרך להחזיר את הנתיב /a/b/c כי הוא הנתיב הארוך ביותר שעדיין מכיל את כולם. ## פיתרון בשפת רובי הפיתרון לתרגיל הוא הזדמנות לדבר על תחיליות משותפות ומבנה הנתונים Trie. זהו מבנה נתונים מבוסס עץ שמייצג פיצול של אחד הקלטים. אם ניקח לדוגמה את הנתיב הראשון אז הוא ייוצג על ידי העץ:

/a
    /b
        /c
            /1
                /x.pl

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

/a
    /b
        /c
            /1
                /x.pl
            /d
                /e
                    /2
                        /x.pl

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

class Node
  attr_accessor :value, :children
  def initialize(value)
    @value = value
    @children = {}
  end

  def <<(path)
    return if path.length == 0

    next_part = path.shift
    @children[next_part] = Node.new(next_part) unless @children[next_part]
    @children[next_part] << path
  end
end

ועכשיו אפשר להכניס את כל הנתיבים שלנו לעץ:

paths = %W[
    /a/b/c/1/x.pl
    /a/b/c/d/e/2/x.pl
    /a/b/c/d/3/x.pl
    /a/b/c/4/x.pl
    /a/b/c/d/5/x.pl
]

root = Node.new("")
paths.each { |path| root << path.split('/') }

ובסוף לרוץ על העץ ולחפש את הנתיב הכי עמוק שמכיל את כולם:

i = root
prefix = ""
loop do
  prefix += '/' + i.value unless i.value.empty?
  break unless i.children.length == 1
  i = i.children[i.children.keys[0]]
end
puts prefix

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

# הפתעות עיקרון בשם POLA, ראשי תיבות של principle of least astonishment, טוען שבעיצוב תוכנה אנחנו רוצים לבנות מערכות שיתנהגו בהתאם לציפיות של רוב המשתמשים. אבל יש פה בעיה - אף אחד לא יכול לדעת מה הציפיות של רוב המשתמשים או מי בכלל יהיו המשתמשים האלה. כשבונים שפת תכנות החיים עוד יותר מסובכים, כי כמעט כל מי שמגיע ללמוד את שפת התכנות שבנית מגיע עם ציפיות משפות תכנות אחרות, וכמעט כל החלטה שתעשה תפתיע הרבה אנשים. מטס, היוצר של רובי, טוען בהקשר הזה שעיקרון Pola בכלל לא אומר ששפת התכנות שלו צריכה להיות הכי פחות מפתיעה לרוב האנשים - אלא שהיא צריכה להיות הכי פחות מפתיעה עבורו. אם הגעת משפה אחרת והופתעת מפיצ'ר מסוים זה בסדר גמור. זה פשוט אומר שההבנה שלך של השפה שונה מזו של יוצר השפה. והנה מצאנו עוד זווית שאפשר ללמוד ממנה על הטכנולוגיה. ניקח לדוגמה את טייפסקריפט הפעם ובואו נדבר על Interface-ים ו Type-ים. בשניהם אני יכול להשתמש כדי להגדיר טיפוס חדש ולהרחיב אותו, לדוגמה עבור כלי תחבורה ומכונית:

interface Vehicle {
  goto: (place: Place) => void;
  wheels: number;
}

interface Car extends Vehicle {
  testValidUntil: Date;
}

ואותו דבר עם type-ים:

type Vehicle = {
  goto: (place: Place) => void;
  wheels: number;
};

type Car = Vehicle & {
  testValidUntil: Date;
}

אבל אז אני מנסה להגדיר את אותו שדה ב Vehicle וב Car עם טיפוסים שונים (למשל שדה בשם x שב Vehicle הוא מסוג number וב Car הוא מסוג string) ומופתע מההבדל בין השניים: בשימוש ב interface-ים הקוד לא יסכים להתקמפל בגלל שהוא לא יודע מה סוג השדה ב interface היורש (במקרה שלנו Car). בשימוש ב type-ים הקוד יתקמפל אבל סוג השדה ב interface היורש לא יהיה אף אחד משני הטיפוסים המתנגשים אלא יהיה never, מה שאומר שאין בעיה לקמפל את הקוד כל עוד לא יצרתי אף משתנה מה type הבעייתי. וההפתעה הזאת נפלאה. כי עכשיו היא פותחת את הדלת להמון שאלות חדשות כמו "מה interface יודע ש type לא יודע?", איך interface מצליח לזהות את הבעייה כבר בהגדרה ו type חייב לחכות עד שנגדיר משתנה מה type הזה? האם זה בכוונה? האם זה מאפשר ל type לעשות דברים ש interface לא יכול לעשות? האם זו מגבלה שהיא חלק מהותי מה Design של השפה ויכולה ללמד אותי משהו על הסמנטיקה של interface-ים ו type-ים ומתי כדאי להשתמש בכל אחד? האם זו מגבלה טכנית שאולי תשתנה בעתיד? האם יש מישהו שרוצה בכלל לשנות את זה? נקודת ההתחלה של השאלות היא הפתעה. הפתעה היא כמו מצפן בשבילנו בתהליך הלימוד, היא תמיד מראה את הכיוון כדי להיכנס יותר לעומק.

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

import React from 'react';

בתחילת כל קובץ JSX. רובנו שמחנו על החיסכון בזמן ועצרנו שם, ובקוד חדש פשוט הפסקנו לכתוב את ה import הזה. זאת הרמה הראשונה. רמת מאחורי הקלעים כבר מדברת על הסיבות בגללן מישהו התאמץ להכניס את הפיצ'ר הזה, והערך הנוסף שהפיצ'ר הזה נותן לאנשים שכותבים כלים בתוך האקוסיסטם של ריאקט. סבסטיאן מרקבג' וונימין קרול כתבו מסמך הסבר די ארוך באותה תקופה על ההגיון ומאחורי הקלעים של ההחלטה כאן: https://github.com/reactjs/rfcs/blob/createlement-rfc/text/0000-create-element-changes.md קריאה של אותו מסמך משנה לגמרי את ההבנה של מה קרה שם ועוזרת לגבש תמונה מלאה על הפיצ'ר והקשר שלו עם יכולות אחרות של ריאקט. יש אנשים שההצצה מאחורי הקלעים מלהיבה אותם יותר מההצגה עצמה; אצל רובנו להצליח להסתכל מאחורי הקלעים ולהתעניין במה שיש שם זאת מיומנות שצריך לפתח. והיא לגמרי שווה את ההשקעה.

# מה עושים עם חסמים פסיכולוגיים חסמים פסיכולוגיים זה כשאנחנו לא מסוגלים לשקול אפשרות מסוימת, למרות שאותה אפשרות אולי תעזור לנו להתקדם. דוגמה מהחיים שמחוץ לתכנות תהיה בן אדם שיש לו כסף בצד אבל לא מוכן לקנות דירה כי "המחירים מטורפים ואין מצב שאני משתעבד למשכנתא", למרות שהחזר המשכנתא יהיה עבורו זול יותר משכירות (גם בניכוי הריבית שאולי הוא צובר על החיסכון), כי הוא גר באזור שבו מחירי ההשכרה יחסית גבוהים למחירי הקניה. כשניכנס לעולם המקצועי נוכל לדמיין דוגמאות יותר קרובות, לדוגמה אפשר לחשוב על מתכנתת שנשארת בעבודה שהיא לא אוהבת כי היא לא מוצאת אופציה יותר טובה, למרות שהיא יודעת שהסיבה שהיא לא מתקבלת לעבודה טובה יותר היא פערי ידע, והדרך היחידה שלה לסגור את הפערים האלה זה לעזוב את העבודה ולהשקיע כמה חודשים בלשבת ללמוד. אותה מתכנתת עשויה להעדיף להישאר תקועה במקום כי היא לא מסוגלת לשקול אפילו את האפשרות לעזוב לכמה חודשים ולא לדעת מה יקרה אחרי. וכשנצלול לקוד נוכל לדבר על המתכנת שלא מעלה על דעתו לכתוב בדיקות, כי בדיקות זה בזבוז זמן, למרות שהוא מעולם לא השקיע את הזמן בללמוד איך לכתוב בדיקות נכון; או המתכנתת שלא תעלה על דעתה לקחת קורס כי "אם למדריך היה שכל הוא היה כותב קוד ולא מלמד". מחסומים פסיכולוגיים לא נראים כמו מחסום, אלא שהם פשוט מסתירים את האפשרות שמאחוריהם. כשאנחנו בתוך הצומת ומנסים לחשוב מה הצעד הבא, אנחנו לא יכולים לדמיין לעשות את הצעד החסום, ואפילו אם מישהו מציע לנו בדיוק את זה אנחנו ניבהל ונמצא אינסוף תירוצים למה זה לא אפשרי. אבל יש גם חדשות טובות: למרות האימה שהם מעוררים, ולמרות שאי אפשר ממש לראות את הדרך שהם חוסמים, את המחסום הפסיכולוגי עצמו יחסית קל לראות. יושבים עם חבר או חברה, מעלים את הבעיה ומבקשים מאותו חבר להציע כמה שיותר אפשרויות וכמה שיותר הזויות. כשתראו שאחת האפשרויות ממש מבהילה אתכם, יש סיכוי שזיהיתם מחסום פסיכולוגי. אחרי שמזהים מתחילה העבודה הקשה של לפרק את אותו מחסום, לחפש נתונים מדויקים, להבין מה באותה אפשרות כל כך מפחיד אותי ומה צריך לקרות כדי שאוכל לחיות עם הפחד. שווה לדבר עם עצמכם על הפוטנציאל של מה יקרה אחרי. אז אם אני חוזר לאותה מתכנתת שפוחדת לעזוב את העבודה, וכשמישהו מציע לך את זה את מיד נלחצת עם איזה "מה פתאום אבל אני חייבת את הכסף" - שווה לשאול: כמה כסף אני באמת צריכה בחודש? האם אני יכולה לארגן תוכנית חיסכון שתעזור לי לעבור את החודשים הקרובים? שווה גם להזכיר שפעם ישבת שנה שלמה בקורס כדי ללמוד להיות מתכנתת, ועוד שילמת עליו כסף, אז למה זה כל כך מוזר לעשות משהו דומה שוב? והכי חשוב לדבר על המשכורת שתהיה לך אחרי שתשבי ללמוד ותגיעי הרבה יותר מוכנה לראיונות הבאים. יותר מדי פעמים נתקעתי על מחסומים פסיכולוגיים חודשים ואפילו שנים, ואני בטוח שגם לכם יש ניסיון עם כאלה. כל פעם כזאת, כשהמחסום נשבר והצלחתי לזוז קדימה, הצער היחיד היה "איך לא עשיתי את זה קודם". זה יכול לעבוד הוא התמריץ הכי טוב שאפשר לבקש.

# בואו נתקן את JSON.parse ב TypeScript בגלל שהחיים יותר מורכבים מתוכניות מחשב, הרבה פעמים בשלב כתיבת הקוד עדיין לא יהיה לנו את כל המידע שאנחנו צריכים כדי לדעת מה יש בכל משתנה. במיוחד בשפה כמו טייפסקריפט, שמתקמפלת ל JavaScript, אנחנו רגילים לכתוב קוד שמגלה מה לעשות גם בזמן ריצה. הבעיה שגילוי מה לעשות בזמן ריצה הולך נגד הרעיון של Type Safety - כי אם אני לא יודע מה יש לי ביד, איך אני יודע שמותר לי לעשות איתו את מה שרציתי לעשות. לדוגמה נניח שאני קורא אוביקט מ local storage ואני חושב שהוא מכיל מחרוזת שהיא ייצוג JSON-י של אוביקט שיש בו שני שדות מספריים עם המפתחות x ו y. הקוד הבא ב JavaScript קורא את האוביקט הזה ומדפיס את סכום המספרים:

const stringifiedValue = localStorage.getItem('value');
const parsedValue = JSON.parse(stringifiedValue);
const sum = parsedValue.x + parsedValue.y;

console.log(`sum = ${sum}`);

אבל כשאדון טייפסקריפט קורא את הקוד הזה הוא חוטף חום: איך אתה יודע, הוא צועק עליי, שבאמת יש ב local storage אוביקט עם המפתח שכתבת? ואיך אתה יודע שהערך הוא באמת מחרוזת שתצליח לתרגם אותה ל JSON? ואם כבר פיענחת אותה ל JSON, איך אתה יודע שלאוביקט שקיבלת יש שדות בשם x ו y והם מספרים? בתרגום ל TypeScript אני צריך להרגיע את כל הדאגות. ניסיון ראשון שלא עובד עשוי להיראות כך:

type TwoNumbers = { x: number, y: number };

const stringifiedValue = localStorage.getItem('value');
const parsedValue: TwoNumbers = JSON.parse(stringifiedValue);
const sum = parsedValue.x + parsedValue.y;

console.log(`sum = ${sum}`);

זה לא עובד בגלל שטייפסקריפט מספיק חכם בשביל להבין ש getItem לא תמיד יחזיר מחרוזת ו JSON.parse לא יכול לעבוד על null-ים, אבל אם אני מתקן את הבעיה הזאת אני מגיע לקוד הבא שדווקא מתקמפל יופי:

import './style.css'

type TwoNumbers = { x: number, y: number };

const stringifiedValue = localStorage.getItem('value');
if (stringifiedValue) {
  const parsedValue: TwoNumbers = JSON.parse(stringifiedValue);
  const sum = parsedValue.x + parsedValue.y;
  
  console.log(`sum = ${sum}`);
}

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

import './style.css'

type TwoNumbers = { x: number, y: number };

function safeJsonParse(text: string): unknown {
  return JSON.parse(text)
}

const stringifiedValue = localStorage.getItem('value');
if (stringifiedValue) {
  const parsedValue: TwoNumbers = safeJsonParse(stringifiedValue);
  const sum = parsedValue.x + parsedValue.y;
  
  console.log(`sum = ${sum}`);
}

כבר התקדמנו! עכשיו טייפסקריפט כבר כועס על ההשמה מ JSON.parse ל parsedValue בגלל שלא בדקנו שהאוביקטים מתאימים. בשביל הבדיקה אני יכול להגדיר פונקציה נפרדת:

type TwoNumbers = { x: number, y: number };

function safeJsonParse(text: string): unknown {
  return JSON.parse(text)
}

function isTwoNumbers(value: any): value is TwoNumbers {
  return (
    'x' in value &&
    typeof value.x === 'number' &&
    'y' in value &&
    typeof value.y === 'number'
  )
}

const stringifiedValue = localStorage.getItem('value');
if (stringifiedValue) {
  const parsedValue = safeJsonParse(stringifiedValue);
  if (isTwoNumbers(parsedValue)) {
    const sum = parsedValue.x + parsedValue.y;
    console.log(`sum = ${sum}`);
  }
}

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

למי שפספסו הקלטה של וובינר ריאקט נייטיב שהתקיים ביום חמישי האחרון: https://www.youtube.com/watch?v=ou_9QtBC2_M

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

price = float(input("Original price is: "))
price_after_discount = price * 0.9

print(f"After coupon discount you'll pay {price_after_discount}")

והפעלה לדוגמה תקינה היא:

$ python removedollar.py
Original price is: 15
After coupon discount you'll pay 13.5

וכמובן שכשמכניסים את המטבע בהתחלה הכל נשבר:

Original price is: $10
Traceback (most recent call last):
  File "/Users/ynonp/tmp/blog/removedollar.py", line 1, in <module>
    price = float(input("Original price is: "))
ValueError: could not convert string to float: '$10'

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

user_price = input("Original price is: ")
price = float(user_price.lstrip("$"))
price_after_discount = price * 0.9

print(f"After coupon discount you'll pay {price_after_discount}")

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

import re

price = input("Original price is: ")
match = re.search(r'([\d.]+)', price)
if match:
    price = float(match.group(1))
    price_after_discount = price * 0.9

    print(f"After coupon discount you'll pay {price_after_discount}")
else:
    print(f"Invalid price {price}")

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

while True:
    try:
        price = float(input("Original price is: "))
        price_after_discount = price * 0.9

        print(f"After coupon discount you'll pay {price_after_discount}")
        break
    except ValueError:
        print("Please type the price as number only (no $ sign)")

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

import sys, string
from readchar import readkey, key

def read_only_numbers(prompt):
    value = ""
    print(prompt, end="")
    sys.stdout.flush()

    while True:
        k = readkey()
        if k == key.ENTER:
            print()
            return float(value)
        if k not in string.digits and k != ".":
            continue

        print(k, end="")
        sys.stdout.flush()
        value += k


price = float(read_only_numbers("Original price is: "))
price_after_discount = price * 0.9

print(f"After coupon discount you'll pay {price_after_discount}")

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

# לא חשבתי על זה לא חשבתי על זה שכשמשנים כתובת מייל צריך לבקש סיסמה, כי ברוב האתרים אפשר ללחוץ "שכחתי סיסמה" ולקבל קישור לאיפוס סיסמה למייל. לא חשבתי על זה שאלמנט יכול להתכווץ אם הוא בתוך flex-box כי ברירת המחדל של flex-shrink היא 1. לא חשבתי על זה שכמות השאילתות שכתבתי תלויה במספר השורות בטבלה. לא חשבתי שקובץ הלוג יגיע לכזה גודל. כל מנגנון שאנחנו מכניסים למערכת יכול להישבר בדרכים שלא חשבנו עליהן. גישה אחת שלא עובדת להתמודד עם הפחד היא לנסות כן לחשוב על הכל מראש, לתכנן עד לפרטים הכי קטנים ולתת לאינסוף אנשי מקצוע לעבור על התוכניות לפני שמעבירים אותן לפיתוח. זה לא עובד כי גם אנשי מקצוע טובים מפספסים וכי עולם התוכנה משתנה כל הזמן. גישה יותר טובה משלבת בין מחקר טוב מראש לבין נכונות לתקן בזמן ריצה: אנחנו לא מוותרים על תכנון. כשנעלה מערכת אנחנו נבדוק איפה הלוגים שלה נשמרים, איפה הגיבויים נשמרים, נפעיל כלים אוטומטיים שיעזרו לנו למצוא בעיות נפוצות בקוד ונכיר את הקוד והכלים שלנו מספיק טוב כדי לא לפשל בדברים ברורים. באותו זמן, כשמישהו מדווח על תקלה מתכנתים טובים לא לוקחים ללב או מתווכחים. אנחנו משתמשים בזה כהזדמנות ללמוד "על מה לא חשבתי הפעם" ומוסיפים לצ'ק ליסט לקראת הפעם הבאה.