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

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

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

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

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

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

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

״אם רק היו לי עוד שעתיים ביום...״ ״אם רק היה לי עוד מתכנת בצוות...״

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

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

https://www.globes.co.il/news/article.aspx?did=1001282616

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

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

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

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

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

def get_numeric_input(prompt):
    while True:
        try:
            return int(input(prompt))
        except ValueError as e:
            print("Sorry, only integers are allowed. Please try again")

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

values = []
for i in range(5):
    values.append(get_numeric_input("Please select a number: "))
print(max(values))

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

res = get_numeric_input("Please select a number: ")
for i in range(4):
    res = max(get_numeric_input("Please select a number: "), res)

print(res)

יש כאן שם של משתנה שהייתי צריך להמציא (res), והקריאה לפונקצית ה input מופיעה פעמיים.

דרך אחרת להגיע לאותו פיתרון היא לעטוף את הפונקציה ב Generator:

def user_numeric_input(prompt):
    while True:
        yield get_numeric_input(prompt)

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

print(reduce(max, islice(user_numeric_input("Please select a number: "), 5)))

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

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

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

אם זה "פיצ'ר" שהלקוח שכח לציין במסמך האיפיון אז הלקוח אשם וצריך להוסיף כסף בשביל לקבל את הפיתוח הנוסף.

הדינמיקה הזאת הרסנית לשני הצדדים.

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

אפשר לשפר את זה אם מוסיפים קצת מגבלות, למשל:

1. אשמח לבנות לך אתר במחיר הקמה של X ש"ח. אנחנו מסכמים על תאריך (דדליין) שבו העבודה מסתיימת והאתר עולה לאוויר לא משנה מה.

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

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

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

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

FROM ubuntu:18.04

RUN apt-get update
RUN apt-get install nodejs
RUN apt-get clean

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

רמז? כדאי לקרוא את התיעוד של דוקר על שכבות בקישור:

https://docs.docker.com/v17.09/engine/userguide/storagedriver/imagesandcontainers/#container-and-layers

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

אבל זה לא מספיק, וכאן מגיע הטיפ השני:

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

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

ככל שתצליחו להיות יותר קרובים לקהל שלכם - כך לקהל יהיה יותר קל להקשיב ולהבין את הנקודה החשובה שבאתם להעביר.

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

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

class Demo:
    def __init__(self, data=[]):
        self.data = data

    def add(self, x):
        self.data.append(x)

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

d = Demo()
print(d.data)

e = Demo([10, 20, 30])
print(e.data)

f = Demo()
print(f.data)

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

d = Demo()
print(d.data)
d.add(10)

e = Demo([10, 20, 30])
print(e.data)

f = Demo()
print(f.data)

ומדפיס עכשיו:

[]
[10, 20, 30]
[10]

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

class Demo:
    def __init__(self, *data):
        self.data = list(data)

    def add(self, x):
        self.data.append(x)

ובאופן כללי אם אנחנו מקפידים לא להעביר בתור Default Value משהו שהוא Mutable לעולם לא תהיה לנו בעיה של שיתוף ערך בלי שהתכוונו.

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

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

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

def sum_all_numbers(*values):
    res = 0
    for v in values:
        if isinstance(v, numbers.Number):
            res += v

    return res

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

def sum_all_numbers_2(*values):
    return sum([NumericValue(x) for x in values])

מדהים נכון? רק שאז ניגשים לכתוב את NumericValue ומגיעים לזה:

class NumericValue:
    def __init__(self, val):
        if isinstance(val, numbers.Number):
            self.val = val
        else:
            self.val = 0

    def __add__(self, other):
        if isinstance(other, int):
            return self.val + other
        elif isinstance(other, NumericValue):
            return self.val + other.val
        else:
            return NotImplemented

    def __radd__(self, other):
        return self.__add__(other)

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

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

def numeric_value(v):
    return v if isinstance(v, numbers.Number) else 0

def sum_all_numbers_3(*values):
    return sum([numeric_value(v) for v in values])

print(sum_all_numbers_3(10, 20, 'f', 'g', '10', 30))

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