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

1. לחשוב לפני שמתחילים לכתוב.

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

3. לתת למחשב לעבוד בשבילנו - הוא אומנם עדיין לא יודע לנהוג כמו שצריך, אבל הוא אף פעם לא שוכח שלבים בעת ביצוע Deploy למערכת.

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

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

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

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

הקוד הזה בפייתון כותב את הטקסט Hello World לקובץ בשם out.txt:

def run(myfile, text):
    myfile.write(text)

f = open('out.txt', 'w')
run(f, 'Hello World\n')
f.close()

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

import multiprocessing as mp

def run(myfile, text):
    myfile.write(text)

f = open('out.txt', 'w')

p = mp.Process(target=run, args=(f, 'hello world'))
p.start()
p.join()

f.close()

הבעיה? הקובץ הפעם נשאר ריק.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sum('123' - '0')

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

sum(int(x) for x in ['1', '2', '3'])

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

בדוגמא כאן חיפוש בגוגל עבור "python substract string from list" מוצא המון תוצאות לא רלוונטיות (בעיקר על הפונקציה remove), לעומת זאת החיפוש "python convert list to integers" מציג את הפיתרון כבר בתוצאה הראשונה. כשגוגל טועה זה כמעט תמיד בגלל ששאלנו את השאלה הלא נכונה.

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

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

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

import fileinput
from functools import reduce
from itertools import chain

def longer(acc, val):
    if len(acc) > len(val):
        return acc
    else:
        return val

def flatten(listOfLists):
    return chain.from_iterable(listOfLists)


print(
    reduce(
        longer,
        flatten(
            map(
                lambda s: s.split(),
                fileinput.input()
            )
        )
    )
)

ואותה התוכנית בשפת Ruby:

class String
  def longer(other)
    length > other.length ? self : other
  end
end

puts ARGF.flat_map(&:split).reduce(&:longer)

ואותה התוכנית בשפת Elixir:

defmodule My do
  def longer(val, acc) do
    if String.length(acc) > String.length(val) do
      acc
    else
      val
    end
  end
end

IO.stream(:stdio, :line)
|> Enum.flat_map(&String.split/1)
|> Enum.reduce(&My.longer/2)
|> IO.puts

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

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

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

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

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

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

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

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

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

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

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

יש טכנולוגיות חדשות שפשוט מוסיפות יכולות ומפשטות מקרי קצה בעייתיים. אין בעיה לכתוב C++ בלי לדעת כלום על C++11, 14 או 17, אבל מי שכן יודע על הרחבות אלו יוכל לכתוב קוד הרבה יותר מדויק. אין בעיה לכתוב היום JavaScript ES5 אבל מי שיודע גם ES6/7/8 יוכל לכתוב את אותם הדברים בצורה יעילה יותר. ובכל מקרה במצבים כאלה לחדש אין קיום בלי הישן.

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

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