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

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

סקרנות היא גישה טובה יותר.

בוא תראה לי,

באיזה גירסאות אתה משתמש?

יש לך פרויקט דוגמה קטן?

למה בחרת להשתמש בכלי בצורה הזאת?

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

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

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

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

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

כמה דברים שאני אוהב לזכור במקרים כאלה-

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

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

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

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

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

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

פוסט זה זמין גם בתור מדריך וידאו למנויי האתר בקישור: https://www.tocode.co.il/boosters/jq

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

a = []
for i in [1, 2]:
    a.append(lambda: i)
for f in a:
    print(f())

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

וכן דרך אחת זו הפונקציה מהפרויקט scope_capture.

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

from functools import partial

a = []
for i in [1, 2]:
    a.append(partial(lambda i: i, i))
for f in a:
    print(f())

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

1. לא צריך להתקין כלום, לא הוספתי תלות חדשה לפרויקט.

2. הקוד משתמש במבנה יותר גנרי - הפונקציה partial. מתכנתים חדשים שיגיעו לקוד אולי ילמדו להשתמש בה גם בהקשרים אחרים.

נשווה את זה לקוד של הספריה scope_capture:

import inspect
from types import FunctionType

def _make_cell(value):
    fn = (lambda x: lambda: x)(value)
    return fn.__closure__[0]

def capture(f):
    try:
        frame = inspect.currentframe()
        fake_globals = {}
        fake_globals.update(f.__globals__)
        fake_globals.update(frame.f_back.f_locals)
        captured_cells = []
        if f.__closure__:
            for cell in f.__closure__:
                captured_cells.append(_make_cell(cell.cell_contents))
        call_fn = FunctionType(
            code=f.__code__,
            globals=fake_globals,
            name=f.__name__,
            argdefs=f.__defaults__,
            closure=tuple(captured_cells),
        )
        return call_fn
    finally:
        del frame

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

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

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

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

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

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

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

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

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

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

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

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

כשאנחנו אומרים ש"קוד זה רק קוד" המשמעות היא-

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

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

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

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

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

לפייתון לא אכפת איזה Generators נרצה לכתוב, אבל יש שני כללים שכשאנחנו חורגים מהם כדאי לחשוב שנית אם Generator הוא הפיתרון הנכון-

1. גנרטור לא מחשב את כל הערכים מראש.

2. גנרטור לא תופס יותר זיכרון ככל שמחשבים יותר פריטים.

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

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

def groupby(sequence, key):
    groups = defaultdict(list)
    for item in sequence:
        groups[key(item)].append(item)

    for key, values in groups.items():
        yield key, values

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

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

import time
import random

def uniq(seq):
    seen = set()
    for i in seq:
        if i not in seen:
            yield i
            seen.add(i)

def random_numbers():
    while True:
        yield random.randint(1, 100)

for i in uniq(random_numbers()):
    time.sleep(2)
    print(i)

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

import time
import random

def random_numbers():
    while True:
        yield random.randint(1, 100)

seen = set()
for i in random_numbers():
    if i not in seen:
        time.sleep(2)
        print(i)
        seen.add(i)