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

נתבונן בתוכנית הבאה בפייתון שמחשבת את ה sh256 של הקובץ /etc/passwd:

import hashlib
from pathlib import Path

data = Path("/etc/passwd").read_text().encode("utf8")
print(hashlib.sha256(data).hexdigest())

וכן העובדה שהקוד עובד רק מחמירה את המצב.

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

אז איך מגיעים לכתוב קוד כזה? נו זה קל, מתחילים עם:

import hashlib
from pathlib import Path

data = Path("/etc/passwd").read_text()
print(hashlib.sha256(data).hexdigest())

מקבלים את הודעת השגיאה:

TypeError: Strings must be encoded before hashing

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

import hashlib
from pathlib import Path

data = Path("/etc/passwd").read_bytes()
print(hashlib.sha256(data).hexdigest())

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

import hashlib
from pathlib import Path

file_path = "/etc/passwd"

try:
    with open(file_path, 'rb') as file:
        file_content = file.read()
        hash_value = hashlib.sha256(file_content).hexdigest()
        print(f"SHA-256 Hash of '{file_path}': {hash_value}")
except FileNotFoundError:
    print(f"Error: File '{file_path}' not found.")
except PermissionError:
    print(f"Error: Permission denied while trying to read '{file_path}'.")
except Exception as e:
    print(f"Error: {e}")

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

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

"מהו דבר אחד שהיית משנה ב X"

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

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

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

עוד סוג מעניין של תשובות זה תלונות על ביצועים. וזה מעולה כי עכשיו אפשר לדבר על פרופיילינג של תוכנית פייתון, על ביצוע פעולות במקביל, על ההבדל בין async.io ל threads ועל ה GIL וכמה יהיה נחמד כשסוף סוף יורידו אותו. אפשר להציע לבנות מודול ב C ולקרוא לו מפייתון ולבדוק אם המועמד או המועמדת שהתלוננו על ביצועים ניסו לעשות את זה.

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

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

מצטט מSoatok כי העצה מושלמת, תרגום שלי:

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

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

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

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

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

הבעיה עם פחד בתור מנטור היא שאנחנו פוחדים מהדברים הלא נכונים, לדוגמה-

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

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

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

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

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

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

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

כי שני המשפטים האלה יחד מובילים אותנו קדימה-

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

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

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

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

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

אין לי מושג איך לגשת לזה. וזה בסדר גמור.

אתם כבר יודעים שהתחלתי לא מזמן ללמוד סקאלה, ואחד הצעדים הראשונים שלי עם שפת תכנות הוא לממש דברים שאני כבר יודע לפתור רק בשביל לראות איך זה עובד. אז הנה פיתרון של Advent Of Code 2022 Day 2 בסקאלה, תוך שימוש נרחב ב match/case שלהם והחצים שנראה שמאפיינים את השפה.

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

ואולי Virtual DOM הוא לא כזה רעיון טוב? או לא כזה מתאים לפרויקט שלך?

ואולי ORM לא היה כזה רעיון טוב? או לפחות לא הכי מתאים לפרויקט שלך?

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

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

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

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

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

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

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

2. קוד אדיב יודע לעבוד קצת בשבילך. הוא לא כולל הרבה תלויות ואם כבר יש הוא יביא אותם איתו. הוא גם יגיע עם תיעוד מקיף שכולל הרבה דוגמאות שאפשר כבר לקחת ולהתחיל מהן.

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

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

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

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

https://codepen.io/ynonp/pen/LYMrbzw

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

document.body.addEventListener("mousedown", () => {
  document.body.classList.add("using-mouse");
});
document.body.addEventListener("keydown", ({ key }) => { 
  if (key === "Tab") { 
    document.body.classList.remove("using-mouse"); 
  } 
});

ובקודפן:

https://codepen.io/ynonp/pen/LYMmmEd

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

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

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

2. בהרצאה אני מרגיש שייך לקבוצה - יש איתי עוד אנשים שלומדים את זה. אני לא לבד.

3. הרגשה שאני יודע על מה מדובר - שאני במקום הנכון. שאני מבין. זה משהו שמאוד קשה לקבל מ AI.

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

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

6. הפתעה - הסיפורים הקטנים שלא תכננתי לשמוע ואולי שווים יותר מהנושא האמיתי.

ומה אתכם? מה אתם תמשיכו לקחת מהרצאות אחרי שנוכל ללמוד הכל מה AI? למה עוד תרצו להמשיך לבוא?