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

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

data = { name: 'my item', price: 15 }

שנראה ממש דומה לקוד הבא בשפה JavaScript:

data = { name: 'my item', price: 15 }

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

data = { 'a' => 10, 'b' => 20 }

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

for i in range(10):
    print(i)

דומה באיזשהו אופן ללולאה הזו מ JavaScript (עם קצת עזרה של lodash):

for (let i in _.range(10)) {
    console.log(i);
}

ושתי התוכניות באמת מדפיסות את אותו דבר אבל עושות משהו אחר לגמרי. במציאות המילה of ב JavaScript היא הדרך לדמות את ההתנהגות של פייתון:

for (let i of _.range(10)) {
    console.log(i);
}

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

מה עוצר אותך מללמוד את הטכנולוגיה החדשה הזאת שכולם מדברים עליה? מלנסות לכתוב אפליקציית מובייל ב React Native? מלכתוב פרויקט צד ב Clojure או ב Elixir או אפילו ב Node.JS? מלהתחיל להשתמש כמו שצריך ב Git?

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

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

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

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

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

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

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

function useTextField() {
  const [value, setValue] = useState('');

  function Input(props) {
    return <input type="text" value={value} onChange={(e) => setValue(e.target.value)} />
  }

  return [Input, value, setValue];
}

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

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

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

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

>>> import asyncio

>>> async def main():
...     print('hello')
...     await asyncio.sleep(1)
...     print('world')

>>> asyncio.run(main())
hello
world

זה עובד. וזה מדפיס hello ו world בדיוק כמו שהם כתבו שיקרה. וזה גם משתמש בהמון מילים של asyncio כמו await, async ו asyncio.run. ובכל זאת אם לא הייתי יודע מה כל הפקודות האלה עושות לא חושב שהייתי מרוויח הרבה מקריאת הדוגמא כאן.

קודם כל כי יש לפייתון את time.sleep ואפשר לכתוב בדיוק את אותה תוכנית עם sleep ולקבל קוד יותר קצר ויותר ברור. ויותר מזה, כי הדוגמא, למרות שהיא עובדת וכוללת את כל המילים, לא מראה את הקסם של תכנות אסינכרוני ואת הדברים היפים ב asyncio. אתה קורא את הקוד וכל מה שבא לך זה לשאול "אבל בשביל מה צריך את זה?". ואגב הדוגמאות לא משתפרות בהמשך דף התיעוד.

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

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

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

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

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

<form>
  <label>
    type something:
    <input type="text" name="text" />
  </label>

  <button>Save</button>
</form>

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

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

<form>
  <label>
    type something:
    <input type="text" name="text" />
  </label>

  <button type="button">Save</button>
</form>

״לקרוא עכשיו ספר מקצועי מקצה לקצה? קצת גדול עליי״

״לכתוב מערכת ווב שאנשים ממש ישתמשו בה? גדול עליי אחי״

״לכתוב מערכת בדיקות אוטומטית במקום להריץ הכל לבד? רעיון טוב אבל כרגע טיפה גדול עליי״

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

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

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

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

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

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

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

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

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

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

set a 10

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

set a 10
set b a

ישמור בתא a את הערך 10 ובתא b את הערך ששמור עכשיו ב a, כלומר גם 10.

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

class MyParser:
    # ...
    def set(self, reg, val):
        ival = self.read_register_or_value(val)
        self.memory[reg] = val

    def sub(self, reg, val):
        ival = self.read_register_or_value(val)
        self.memory[reg] -= ival

    def mul(self, reg, val):
        ival = self.read_register_or_value(val)
        self.memory[reg] *= ival

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

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

דרך אחת להפוך את הקוד לקצת יותר נעים לעין היא להמיר את הקריאה היזומה בקריאה ל Decorator:

class MyParser:
    @read_value_from_register
    def set(self, reg, val):
        self.memory[reg] = val

    @read_value_from_register
    def sub(self, reg, val):
        self.memory[reg] -= val

    @read_value_from_register
    def mul(self, reg, val):
        self.memory[reg] *= val

כל מה שצריך בשביל המעבר למבנה החדש הוא להגדיר את הפונקציה read_value_from_register מחוץ למחלקה בתור Decorator:

def read_value_from_register(f):
    def inner(self, reg, val):
        ival = self.read_register_or_value(val)
        f(self, reg, ival)

    return inner

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

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

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

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

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

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

ומתוך דה מרקר:

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

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

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