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

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

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

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

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

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

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

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

אם לא הצלחת להגיע למטרה שרצית, אולי שווה לנסות שיטה אחרת.

אחד השילובים שאני יותר אוהב בפיתוח הוא Redux ו Web Sockets. זה עובד ממש פשוט ויפה יחד: כל פעם שמגיע אירוע מבחוץ דרך ה Web Socket, יהיה לנו מידלוור שיתרגם את האירוע לאוביקט Redux Action, האוביקט ייכנס למערכת דרך ה Reducers ובאופן אוטומטי המסך יתעדכן כי ריאקט יזהה את השינוי וימשוך את המידע החדש.

בואו נכתוב שלד קצר להמחיש את הרעיון באמצעות שרת Firebase.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. יש יותר סיכוי שתתאמצו לפתור את החידות של Advent Of Code בחודש דצמבר מאשר אם תנסו לפתוח אותן בפברואר.

3. יש יותר סיכוי שתצליחו להיכנס לכושר אם תצטרפו לקבוצת ריצה, מאשר אם תנסו לרוץ בקצב שלכם.

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

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

הספריה pytest-asyncio היא פלאגין ל pytest שמוסיפה אפשרות לסמן בדיקות או Fixtures בתור בדיקות אסינכרוניות ובאופן אוטומטי תפעיל את הבדיקות האלה בתור קורוטינות ותעביר להן את ה event loop.

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

@pytest.mark.asyncio
async def test_luke_name(aiosession):
    data = await fetch(aiosession, 'https://swapi.co/api/people/1/')
    assert data['name'] == 'Luke Skywalker'

בדיקה זו משתמשת בפונקציית עזר בשם fetch (אסינכרונית גם היא) וב Fixture אסינכרוני בשם aiosession. הנה הקוד לשניהם:

@pytest.fixture()
async def aiosession():
    async with aiohttp.ClientSession() as session:
        yield session

async def fetch(session, url):
    async with session.get(url) as response:
        return await response.json()

כל Fixture אסינכרוני מוגדר באופן אוטומטי להיות בעל תחום הגדרה של פונקציה. בשביל להשתמש בתחום הגדרה גדול יותר אנחנו צריכים לדרוס את ה Fixture שנקרא event_loop של ספריית pytest-asyncio ולתת לו תחום הגדרה גדול יותר. בדוגמא הבאה אני מגדיל את תחום ההגדרה של aiosession כך שיישמר לאורך כל חיי תוכנית הבדיקה:

@pytest.fixture(scope='session')
def event_loop():
    loop = asyncio.get_event_loop()
    yield loop
    loop.close()


@pytest.fixture(scope='session')
async def aiosession():
    async with aiohttp.ClientSession() as session:
        yield session

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

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

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

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

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

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

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