ToCode

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

for i in range(0, 10):
    print("{} Hello World".format(i))

כי זה נראה ממש דומה לקוד ה Java:

for (int i=0; i < 10; i++)
    System.out.println(String.format("%d Hello World", i));

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

for (int i=9; i >= 0; i--)
    System.out.println(String.format("%d Hello World", i));

ב Python ניסיון להפוך את סדר המספרים ב range כמובן נכשל ולא מדפיס כלום:

for i in range(10, 0):
    print("{} Hello World".format(i))

ככל שנלך רחוק יותר בחקירה שלנו נגלה שקוד Python עושה דבר דומה לקוד ה Java, אבל בדרך מאוד שונה. בגירסת ה Java אנחנו יודעים מה זה לשמור את המספר 0 במשתנה או לשנות את ערך המשתנה ב-1. בגירסת ה Python בשביל להבין מה קורה בלולאה אנחנו צריכים להבין ש range בכלל מחזירה אוביקט שיש לו פונקציה בשם __iter__, שמחזירה משהו שיש לו פונקציה בשם __next__, ושבצורה אוטומטית for מפעיל את __iter__, לוקח את הדבר שהחזירה ומפעיל עליו __next__ עד שמקבל את ה Exception המיוחד שאומר שנגמרו כל האיברים. כלומר אם אני מנסה מתוך ה REPL להבין למה ה range לא עבד זה עשוי להיות מבלבל. בכתיבה הראשונה שתי הפקודות מחזירות תוצאה דומה:

>>> range(0, 10)
range(0, 10)
>>> range(10, 0)
range(10, 0)
>>>

ורק בהמשך חקירה אני מצליח לראות את הבעיה:

>>> len(range(0, 10))
10

>>> len(range(10, 0))
0

וכמובן:

>>> g = range(0, 10)
>>> i = iter(g)
>>> next(i)
0
>>> next(i)
1

# But ...

>>> g = range(10, 0)
>>> i = iter(g)
>>> next(i)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

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

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

# כלים וטכניקות מתכנתי JavaScript רגילים לכתוב קוד בצורה אסינכרונית הרבה יותר מאשר מתכנתי Java, ומתכנתי Java רגילים הרבה יותר לסנכרן משימות בין Threads בהשוואה למתכנתי JavaScript. כל זה למרות שיש ל Java מנגנון תכנות אסינכרוני, ול JavaScript יש WebWorkers ו SharedArrayBuffer. באותו אופן למרות שאין מניעה עקרונית מכתיבת קוד פונקציונאלי ב Python, ואין שום בעיה להגדיר משתנה גלובאלי ולשנות אותו ב Clojure, מתכנתי Python בדרך כלל יעדיפו לשמור את המידע שלהם במשתנים ולשנות את ערכיהם לאורך ריצת הפונקציה, ומתכנתי Clojure יעשו מאמץ גדול יותר כדי לכתוב פונקציות טהורות. הכלים שאתם בוחרים ואיתם התרבות, התיעוד ושאר הקוד שכבר ראיתם ממקדים את המבט בטכניקות עבודה מסוימות. הבעיה שלאורך זמן אנחנו נקשרים לטכניקות האלה וכשנסיבות חיצוניות מכריחות אותנו לעבור לכלי אחר אנחנו עלולים לחוות קשיי הסתגלות. לכן תרגיל ששווה לנסות בפעם הבאה שיש לכם קצת זמן הוא מימוש טכניקה שאתם לא רגילים אליה אבל בשפה הרגילה שלכם: כתבו תוכנית פייתון המורכבת מפונקציות טהורות בלבד, או נסו לבנות תוכנית JavaScript שעושה דברים במקביל עם Web Workers. חיפוש ומימוש טכניקות חדשות בשפה שאנחנו כבר מכירים ושולטים בה זו דרך מהנה גם ללמוד דברים חדשים על השפה הראשית שלנו, וכמובן להיחשף לעולמות חדשים שיעזרו לנו ביום שנצטרך להחליף.

# תשובה עכשיו קשה להאמין שעד לפני 2008 לא היה דבר כזה שנקרא Stack Overflow. רגע מה Stack Overflow עד 1994 לא לכם אינטרנט בבית, וכנראה אפילו קצת יותר מאוחר. זה אומר שאם כתבתם קוד למשל ב 1992, סתם, בבית, בשביל הכיף, ונתקעתם - באמת לא היה את מי לשאול. אז היית הולך לספריה ומחפש ספר על תכנות או מוצא איזה חבר או שכן שכן אולי יודע ויכול לעזור וכל העסק הזה היה עובד ממש ממש לאט. שלא לדבר על זה שהיו הרבה פחות ספריות קוד מוכנות כך שהיית צריך לכתוב הרבה יותר קוד תשתית בסיסי. אם אתם במצב רוח לטעימה מההיסטוריה האמיתית של לימודי תכנות מומלץ לקרוא את הערך Type In Program בויקיפדיה. העולם שאחרי StackOverflow ו npm הוא הרבה יותר פרודוקטיבי, אבל גם הרבה יותר מיידי. היום כשאני מחפש תשובה ברשת זה טבעי להתחיל עם חיפוש בגוגל, לפתוח עשרה טאבים עם כל התוצאות ולרוץ ביניהם בחיפוש אחר הקוד או ספריית התוכנה הרלוונטית שתפתור לי את הבעיה עכשיו. יום אחרי יום ושאלה אחרי שאלה ותרבות הפיתוח משתנה. היום כבר קשה למצוא את הסבלנות לשבת על אותה בעיה שבוע או שבועיים (או יותר) עד שמגיעים לפיתרון הטוב ביותר. ואין מה לדבר על הסבלנות לשבת ולכתוב מאפס פיתרון או קוד תשתית. וזה חבל כי סבלנות ופיתוח מאפס הם בדיוק המאפיינים שהופכים אותנו לתלמידים טובים יותר. הסבלנות לשאול עוד ועוד שאלות, להיכנס לקוד של ספריות תוכנה שמצאנו ולהבין איך הן עובדות ולמה הן כתובות כך, או לכתוב משהו לבד לפני שמסתכלים על ספריה קיימת ואז ללכת ולבחון 3-4 ספריות קיימות כדי להבין את הגישות השונות. "מה הפיתרון הנכון לתרגיל?" זו כמעט אף פעם לא שאלה טובה כשבאים ללמוד משהו חדש. "אני פתרתי ככה, ומה את עשית?" או "חשבתי על כיוון כזה, יש לך רעיונות לשיפור?" יעבדו הרבה יותר טוב.

# הי, ראית כבר את... יש הבדל גדול בין ה Concurrent Mode החדש של ריאקט לבין ריאקט הוקס. ואני לא מתכוון שהראשון ניסיוני והשני כבר מזמן בפרודקשן, אלא הבדל מבחינת מה אפשר לעשות עם הדבר הזה. ריאקט הוקס זה פיצ'ר חדש שלוקח משהו שעשית ממילא והופך אותו להרבה יותר פשוט. זה פותר את אותה בעיה בצורה טובה יותר. זה מעולה. לעומתו Concurrent Mode פותר בעיה שהרבה אנשים בכלל לא נגעו בה לפני כן. היא היתה קיימת פשוט התעלמנו ממנה או הלכנו לידה. ברור שיישומים שישתמשו ב Concurrent Mode יוכלו להגיע לביצועים טובים יותר, אבל בשביל יישומים שרוצים להגיע לאותה חוויה בה הם היו קודם אפשר לדלג על זה. דוגמא דומה להבדל הזה מ TypeScript היא ההבדל בין האופרטור ?. ל Assertion Functions. הראשון עוזר לקצר קטעי קוד כאלה שכמעט כולם כותבים:

let x;
if (foo != null) {
    if (foo.bar != null) {
        if (foo.bar.buz != null) {
            x = foo.bar.buz();
        }
    }
}

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

x = 1_000_000

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

# לימודים בתקופה של אי וודאות השבועות האחרונים זרקו אותנו לעולם מאוד מוזר בכל מה שקשור ללימודים - מצד אחד כל הפייסבוק שלי מלא באנשים שמזמינים אותי לקחת את הקורס אונליין שלהם או ללמד אותי איך להקליט ולמכור קורס אונליין משלי. אבל מצד שני להרבה אנשים ברור שאנחנו לא באמת יודעים איזה מיומנויות נצטרך כשהחיים יחזרו למסלולם. אם עד אתמול מחפשי עבודה ידעו מה הדרישות בשוק, בשבועות האחרונים מספרים לי הרבה חברים על הקפאה של תהליכי גיוס (כולל כאלה שהתחילו). אם חיפשתם עבודה כמפתחי Front End והקפיאו לכם את החיפוש, יכול להיות שאתם משוכנעים שעוד רגע הכל יופשר ויחזור לקדמותו, אבל יותר סביר שאתם מבינים שאי אפשר לדעת איך יראה העולם כשחברות יחזרו לגייס. אנחנו לא יודעים איזה חברות ייסגרו ואיזה חברות חדשות יקומו, ואנחנו בטח לא יכולים להיות בטוחים שדווקא פיתוח פרונטאנד (או פייתון, או Machine Learning) יהיו הדברים שבהם נצליח למצוא עבודה. וחוסר הוודאות הזה הופך את הלימוד להרבה יותר מורכב, כי בנוסף על הדאגה הרגילה של מחפשי עבודה אנחנו מוסיפים גם את הדאגה הכללית שלא ברור מתי בכלל עבודות ייפתחו שוב, מה תהיה התחרות ואיזה עבודות אלה יהיו. לכן דווקא בתקופה כזו של אי וודאות יותר קל להוריד הילוך. בניגוד למה שלפעמים נראה מהפייסבוק העולם לא בורח לשום מקום, אין אוצר מטבעות זהב בקצה הקשת בענן ואין שום סיבה לרוץ דווקא עכשיו מהר אחרי הדבר הגדול הבא. אין לאף אחד מושג ירוק מה יהיה הדבר הגדול הבא. הלימוד בהילוך איטי הוא שונה מהלימוד המתוקתק והפרודוקטיבי שאנשים רגילים אליו. אפשר למשל לקחת חצי שעה בערב ולראות הרצאה מכנס במקום נטפליקס. אפשר לנסות בבוקר לפתור שאלה מראיונות עבודה, סתם בשביל הכיף. אפילו אם אתם רוצים לחלום ולהתקדם בפרויקט צד קטן זה כיף. הדגש הוא על לימוד שעושה כיף ובמקטעים קטנים במקום לימוד כדי להשיג מטרה, כי המטרה שאנחנו רודפים אחריה אולי לא תהיה שווה הרבה בעוד חודשיים. כמה דוגמאות? ברור בשביל זה אנחנו פה: 1. טוטוריאל פיתוח משחק פלאפי בירדס מלא בעשר דקות 2. פרויקט אוילר 3. אדוונט אוף קוד 4. קראקמיס 5. וים בייסיקס בשמונה דקות 6. ובאותו נושא וים אדוונצ'רס 7. פלקסבוקס צפרדעים 8. אפשר לפתוח בלוג מקצועי קטן ועל הדרך ללמוד קצת על פיתוח ואחסון אתרים

# ביי ביי swapi.co זה לקח לי כמה עשרות ניסיונות ריענון של האתר עד שהגעתי למסקנה הכואבת... swapi.co החזיר את נשמתו לאלוהי האינטרנט. הזיכרון האחרון ממנו שמור ב Wayback Machine ומתוארך ל 8.3, שזה לפני קצת יותר מחודש. אז למי שלא הכיר (ועכשיו כבר לעולם לא יכיר), swapi.co היה אתר ששמר בסיס נתונים על כל הדמויות במלחמת הכוכבים. אבל זה בסיס נתונים כמו ב imdb שמכריח אותך לקרוא את הכל מהאתר שלהם, אלא בסיס נתונים עם API פתוח. גלישה לדוגמא לכתובת https://swapi.co/api/people/1/ היתה מביאה לכם בחזרה אוביקט JSON עם כל הפרטים שיכולתם לדמיין על Luke Skywalker. פניה לכתובת https://swapi.co/api/starships/12/ היתה מחזירה דף מידע מפורט על ה X-Wing, כולל כל הפרטים הטכניים על החללית ורשימת כל הדמויות שהטיסו אותה. ואפילו יותר חשוב ממאגר המידע המדהים היה העובדה ש swapi נשאר פתוח ולא ביקש מכם הרשמה, לא מפתח סודי ואפילו לא רצה לדעת איך קוראים לכם. מספיק היה לגשת לכתובת המתאימה כדי לקבל את המידע מכל מכשיר. המגבלה היחידה היתה Firewall ידידותי שדאג לחסום כתובת IP אם ניגשתם יותר מדי פעמים בזמן קצר מדי, וממילא החסימה היתה נפתחת אוטומטית חזרה אחרי כמה שעות. שלשום פול האלט העלה את הקומיט האחרון למאגר של swapi.co עם הודעה על הפסקת התמיכה (נכון, כבר ב 2016 הוא דיבר על להוריד את האתר. אבל לא חשבתי שזה באמת יגיע יום אחד). לשמחתנו ה API של הפוקימונים עדיין באוויר, אבל קשה להרגיש ביטחון גם לגביו. תודה פול על שש שנים נפלאות.

# ביי ביי swapi.co זה לקח לי כמה עשרות ניסיונות ריענון של האתר עד שהגעתי למסקנה הכואבת... swapi.co החזיר את נשמתו לאלוהי האינטרנט. הזיכרון האחרון ממנו שמור ב Wayback Machine ומתוארך ל 8.3, שזה לפני קצת יותר מחודש. אז למי שלא הכיר (ועכשיו כבר לעולם לא יכיר), swapi.co היה אתר ששמר בסיס נתונים על כל הדמויות במלחמת הכוכבים. אבל זה בסיס נתונים כמו ב imdb שמכריח אותך לקרוא את הכל מהאתר שלהם, אלא בסיס נתונים עם API פתוח. גלישה לדוגמא לכתובת https://swapi.co/api/people/1/ היתה מביאה לכם בחזרה אוביקט JSON עם כל הפרטים שיכולתם לדמיין על Luke Skywalker. פניה לכתובת https://swapi.co/api/starships/12/ היתה מחזירה דף מידע מפורט על ה X-Wing, כולל כל הפרטים הטכניים על החללית ורשימת כל הדמויות שהטיסו אותה. ואפילו יותר חשוב ממאגר המידע המדהים היה העובדה ש swapi נשאר פתוח ולא ביקש מכם הרשמה, לא מפתח סודי ואפילו לא רצה לדעת איך קוראים לכם. מספיק היה לגשת לכתובת המתאימה כדי לקבל את המידע מכל מכשיר. המגבלה היחידה היתה Firewall ידידותי שדאג לחסום כתובת IP אם ניגשתם יותר מדי פעמים בזמן קצר מדי, וממילא החסימה היתה נפתחת אוטומטית חזרה אחרי כמה שעות. שלשום פול האלט העלה את הקומיט האחרון למאגר של swapi.co עם הודעה על הפסקת התמיכה (נכון, כבר ב 2016 הוא דיבר על להוריד את האתר. אבל לא חשבתי שזה באמת יגיע יום אחד). לשמחתנו ה API של הפוקימונים עדיין באוויר, אבל קשה להרגיש ביטחון גם לגביו. תודה פול על שש שנים נפלאות.