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

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

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

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

1. מספיק סקאלה כדי שאפשר יהיה לעבוד - תחנה ראשונה תהיה לפתור את התרגילים הראשונים של פרויקט אוילר וכמה שאלות מ Advent Of Code וכל מיני אתגרי הכנה לראיונות עבודה רק בשביל לראות שאני מצליח לכתוב קוד בסיסי בשפה. אני מקווה לכל תוכנית שאכתוב להוסיף גם תוכנית בדיקה כדי להבין איך עובד מנגנון הבדיקות בסקאלה.

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

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

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

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

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

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

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

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

בוא תראה לי,

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

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

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

לפעמים כשיהיה לי מספיק מידע על הבעיה אני אוכל מיד לעזור לחבר להבין את הכלי, משהו כמו "בשביל לקבל תוצאות טובות עם 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". ככל שנקפיד להוציא את הכותבים מהקוד ולהפוך אותו לתוצאת עבודה משותפת של כל הצוות כך יהיה קל יותר לשתף אחריות, אשמה וגם לשכתב כשצריך.

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