ToCode

# אפליקציית Swift UI הראשונה שלי ב 2008 קניתי את הסמארטפון הראשון שלי כי חשבתי שזו פלטפורמה מלהיבה להרצת קוד - מחשב שזמין בכל מקום, כולל שבב GPS, מצלמה וחיבור קבוע לרשת. זה היה N95 של נוקיה ולקח לי כמעט חצי שנה עד שהבנתי איך שפת המאקרו-אים שהם בנו מעל C++ עובדת והצלחתי לבנות אפליקציה. ב 2011 קניתי אייפון פחות או יותר מאותן סיבות של ה N95, הפעם עם תוספת מסך מגע. אובג'קטיב סי היתה משמעותית יותר קלה מ Symbian ולקח לי רק כמה ימים לבנות את האפליקציה הראשונה בזה. מאז למדתי פונגאפ, ריאקט נייטיב ופלאטר והשבוע באיחור אופנתי החלטתי לתת צ'אנס ל Swift UI, הפריימוורק הנוכחי של אפל. הניסוי הוכתר כהצלחה ותוך פחות משעה כבר היתה לי אפליקציה פשוטה רצה על הטלפון. הנה קובץ הקוד המרכזי:

import SwiftUI

struct ContentView: View {
    @State private var count = 0
    
    var body: some View {
        VStack {
            Text("Turtle Rock... \(count)")
                .font(.title)
                .foregroundColor(.orange)
            .padding()
            Stepper(value: $count, in: 1...10) {
               Text("Hello")
            }
            Button("Click Me", action: {
                self.count += 1
                print("count = \(count)")
            })
        }
            
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

בגדול אם תפעילו את הקוד ב XCode הקרוב אליכם תגלו ש: 1. הקוד מציג על המסך טקסט, מתחתיו משהו שנקרא Stepper (תכף ארחיב עליו) ומתחתיו כפתור. בטקסט כתוב המשפט Turtle Rock ואחריו מספר. לחיצה על הכפתור מעלה את המספר ב-1 2. מתחת לכפתור יש דבר שנקרא Stepper שמורכב מטקסט, כפתור פלוס וכפתור מינוס. לחיצה על הפלוס מעלה את המספר ב-1, לחיצה על המינוס מורידה אותו באחד, והערכים שאפשר להגיע אליהם עם כפתורים אלה הם המספרים בין 1 ל 10. וכמה מילים על הקוד עצמו: 1. ב Swift מה שמופיע על המסך הוא View, ואפשר להגדיר View-ים משלנו. כל View הוא דבר שנקרא struct שזה משהו שהזכיר לי קלאס משפות אחרות. בקוד המודבק יצרתי View בשם ContentView. 2. ל View יש פונקציה בשם body שמחזירה את תוכן ה View, שגם הוא בעצם מורכב מ View-ים אחרים. בתוך הפונקציה יש כתיב מוזר שמייצג את היררכיית ה View-ים, אבל חייב להודות שבשעה שהשקעתי ב Swift לא התעמקתי עדיין במשמעות של זה. 3. ב View אפשר להגדיר גם שדות מידע שנקראים State. כששדה מידע כזה מתעדכן אוטומטית הערך העדכני שלו ייכתב למסך. 4. אלמנט VStack לוקח את ה View-ים שתתנו לו ומציג אותם על המסך אחד מתחת לשני. 5. אלמנט Text הוא View שמציג טקסט. 6. ה Stepper הוא לדעתי החלק הכי מעניין בקוד. הוא מקבל סוג של "הפניה" למשתנה count כדי שיוכל לשנות את ערכו, ובגלל זה צריך היה לכתוב $count. 7. החלק הקשה היה להריץ את הקוד על הטלפון. היה צריך להתחבר עם ה Apple ID שלי ל XCode, ואחר כך בטלפון להיכנס להגדרות ולסמן שאני מוכן להריץ יישומים שאני כתבתי. לא צריך לשלם לאפל בשביל לכתוב קוד ולהריץ אותו על הטלפון שלכם, אבל בשביל לכתוב ולהפיץ בחנות הם ירצו את ה 99$ לשנה שלהם. סך הכל השעה הראשונה עם סוויפט עברה לי ממש חלק. אם אתם באקוסיסטם של אפל לימוד סוויפט נשמע כמו השקעה מוצלחת.

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

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

test('array length returns its size', () => {
  const arr = [1, 2, 5];
  expect(arr.length).toEqual(3);
});

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

class UserManager {
    constructor() {
        this.name = process.env["USER"];
    }
    
    isAdmin() {
        return this.name === 'ynon';
    }
}

אולי הייתם רוצים לכתוב בדיקת יחידה שמוודאת שהפונקציה isAdmin מחזירה true למשתמש בשם ynon ו false למשתמשים בשמות אחרים. הבעיה שבדיקה כזאת תלויה במשתנה סביבה USER וככה יוצא שאתם בודקים יותר ממה שרציתם לבדוק (או שיוצרים Mock ואז מייצרים תלות גדולה מדי בין קוד הבדיקה לקוד המערכת). דרך אחת קלה לצאת מהסיפור הזה היא לבנות אוביקט this עצמאי בתחילת הבדיקה ולהשתמש בו. ב JavaScript זה יהיה:

test('UserManager#isAdmin', () => {
    it('returns "true" for user "ynon"', () => {
        expect(UserManager.prototype.isAdmin.call({ name: 'ynon' })).toEqual(true);
    });
});

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

test('array#push', () => {
    const arr = [1, 2, 5];
    arr.push(10);
    expect(arr.length).toEqual(4);
    expect(arr[3]).toEqual(10);
});

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

function throwDice(sides) {
  return Math.floor(Math.random() * sides) + 1;
}

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

# פריימוורק מעל פריימוורק (או: למה קוד מסתבך) ליאור בר און כתב פוסט מעניין על Execution ובהערת אגב הוא כותב שם ש"מערכות תוכנה נוטות להסתבך ולהיות קשות יותר להרחבה ככל שהן גדלות / הזמן עובר". יש הרבה סיבות לתופעה הזאת (וגם ליאור כותב עליהן במקומות אחרים) ופה אני רוצה להתמקד בתופעה שנקרא לה "פריימוורק על פריימוורק". אם נסתכל על ההבדל בין מערכות פשוטות למערכות מורכבות, נראה שמעבר למספר שורות הקוד יש מאפיין אחד בולט למערכות מורכבות: הן כוללות הרבה יותר שורות קוד שאנחנו כתבנו לעומת שורות קוד מהפריימוורק. אם נניח בחרנו לדבר על ריאקט, אז פרויקט ריאקט הופך להיות מעניין כשיש לנו יותר שורות קוד שאנחנו כתבנו מאשר שורות קוד בריאקט עצמו, או כשרוב מוחלט של העבודה קורה בקוד שלנו. יש סוגי מערכות ופריימוורקים שהרגע הזה יגיע בהם מאוד מאוחר, ואחרים שהוא יגיע בהם מאוד מוקדם. הניסיון שלי עם Rails הראה שבמערכות CMS או בלוגים ובשימוש נכון בריילס קשה מאוד "לצאת" מהפריימוורק ולהגיע לנקודה בה רוב העבודה קורית אצלך. מצד שני בפרויקטי Front End הנקודה הזאת מגיעה מהר מאוד. אפשר להגיד שפריימוורק הוא אבסטרקציה על מערכת מסוימת, וככל שהמערכת שאנחנו בונים שונה מהמערכת שהפריימוורק נגזר ממנה, כך נברח יותר מהר מהפריימוורק ונוסיף עליו רכיבים משלנו. במילים אחרות אפשר להסתכל על הפריימוורק בתור "מסלול" שלוקח אותי יד ביד בבניית מערכת מסוג מסוים. בפרונטאנד אוהבים לתת את דוגמת ה Todo App בתור דוגמה לכל פריימוורק JavaScript, וככה לאורך זמן הפריימוורקים האלה הפכו למסלול לבניית Todo Apps. אם זה מה שאתם צריכים לבנות המערכת שלכם תישאר מאוד פשוטה. אבל בגלל שאנחנו בונים משהו אחר, ובגלל שבעולם הפרונט אנד אנחנו בדרך כלל משלבים המון ספריות קטנות ליד הפריימוורק, נוצר מצב שכל מערכת היא הרכבה של המון המון חלקים קטנים ולא תמיד קשורים. הפריימוורק המקורי שהשתמשנו בו הוא אולי React, אבל בפועל הפריימוורק שאני משתמש בו הוא ריאקט יחד עם אוסף כל החבילות הקטנות מ npm שהתקנתי יחד עם כל הקוד שלי שמדביק את כל החלקים האלה יחד. התוצאה של כל אלה היא פריימוורק חדש - פריימוורק פרטי, ייחודי למוצר שלי, שנכתב בלי תכנון מראש ובכל זאת בתוכו אני עובד. כמתכנתים היום אנחנו רגילים לחפש בגוגל פיתרונות לבעיות נפוצות כשמשהו לא עובד. במיוחד מתכנתי פרונטאנד שלמדו לבד איך לכתוב קוד ואולי בנו לעצמם פרויקט Green Field (כלומר פרויקט שמתחיל מאפס ומשתמש בפריימוורק בצורה נקיה). אבל אם ננסה לחפש בגוגל פיתרון לבעיה בפרויקט קיים נגלה שיש אינסוף פיתרונות ואף אחד מהם לא רלוונטי עבורנו. אוסף הספריות וקוד הדבק שלנו, הפריימוורק-מעל-פריימוורק שלנו, הוא ייחודי כל כך עד שאי אפשר לחפש בגוגל תשובות אפילו לדברים שנראים מאוד בסיסיים. הפריימוורק-מעל-פריימוורק שכתבנו גם צריך תחזוקה, ובגלל שאנחנו לא חושבים על עצמנו כמפתחי פריימוורק (יש לנו מוצר לבנות), אז אנחנו לא מוצאים זמן לתחזוקה הזאת. קשה למצוא זמן לעדכן את התלויות או לעשות Refactoring לקוד הדבק שבנינו. אפילו את הבדיקות לא תמיד מוצאים זמן לתקן. וככה אנחנו נשארים עם "פריימוורק" לא יציב ומתפלאים שככל שהמוצר מסתבך התחזוקה הופכת קשה יותר והבאגים הלא ברורים מתרבים. אנחנו חולמים לחזור לפרויקט Green Field בלי להבין שגם בפעם הבאה שנמחק הכל ונתחיל מחדש הסיבוך יגיע שוב, כי הסיבוך הוא תוצאה של תהליכי עבודה וסדרי עדיפויות. החדשות הרעות הן שאין פיתרונות קלים. לבנות פריימוורק זה הרבה עבודה והפריימוורקים הקיימים ב Front End באמת לא מספיק טובים בשביל האפליקציה שלכם. מצד שני ברגע שאתם רואים שבניתם פריימוורק בלי להתכוון, תוכלו לקחת את הצעד הבא ולהתחיל לתחזק אותו. לאורך זמן זאת הדרך היחידה לגדול.

# הסחות דעת מתכנתים אוהבים לקטר על כל דבר שמפריע לנו לשבת לתכנת כל היום: פגישות, תקלות פרודקשן, אנשי פרודקט שמשנים את דעתם מעכשיו לעכשיו. אנחנו אומרים שכל הסחת דעת כזאת יכולה להחזיר אותנו גם חצי שעה אחורה בעבודה, ויש שיגידו שאפילו שאלה של כמה שניות יכולה לעלות להם בדקות ארוכות של מחשבה עד שמוצאים מחדש את הקשב. וכמו שיש הסחת דעת ביום תכנות יש גם הסחות דעת יותר גדולות בקריירה: 1. עלות שקועה - העובדה שכבר למדתי 10 שנים Java גורמת לי להעדיף משרת מתכנת Java מאשר עבודה אחרת, למרות שהעבודה האחרת אולי יותר משתלמת כלכלית לטווח הרחוק. כל פרויקט חדש שאני לוקח בטכנולוגיה הישנה רק הופך את המעבר לטכנולוגיה החדשה ליותר קשה. 2. הסתכלות על הטווח הקצר - העובדה שעכשיו יש לי הזדמנות לקחת פרויקט X לא אומרת שהפרויקט הזה בריא בשבילי; היא רק אומרת שלקוח מסוים עם פרויקט X עכשיו מצא אותי. הפרויקט הזה יכול לחסום לי הזדמנות ולעכב את הצמיחה שלי בחודשים ארוכים. 3. פחד - האם תהיה לי עבודה בטכנולוגיה החדשה? האם אי פעם אצליח להיות טוב ב"למידת מכונה" כמו שאני טוב ב Java? האם Swift זה לא עוד טרנד חולף שעוד שנתיים יעלם? עדיף כבר להמשיך במה שאני עושה היום. 4. "מה אתה מקטר, החיים שלך דבש" - כלוב הזהב של עבודה בהייטק בנוי כדי להסיח את הדעת מהשינויים המהותיים שקורים בשוק העבודה ומההזדמנויות החדשות שנפתחות. גם אם החיים נראים דבש למישהו שמסתכל מבחוץ, רק אתם יודעים מה אתם מרגישים באמת. שיגרה היא גם סוג של הסחת דעת שמפריעה להגיע לחיים שאתם רוצים. לבנות קריירה מוצלחת זה גם ככה קשה. כשאתם מזהים שלא מצליחים להתקדם שווה להתאמץ להסתכל מה מסיח אתכם מהמטרה ולצמצם הסחות דעת. העלות שלהן הרבה יותר גבוהה ממה שנדמה.

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

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

private String[] userAgents = new String[] {
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36", // 13.5%
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36", // 6.6%
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0", // 6.4%
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0", // 6.2%
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Safari/537.36", // 5.2%
  "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 Safari/537.36" // 4.8%
};

connection.setRequestProperty("User-Agent", userAgents[(int) Math.round(Math.random() * (userAgents.length - 1))]);

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

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

# שלושה מכשולים שבגללם אתה מסתבך עם דוקר דוקר הוא אחד מכלי הפיתוח הכי חשובים של השנים האחרונות, ובכל זאת מתכנתים לא לומדים אותו מספיק. כשאנחנו מגיעים למקום עבודה שמשתמש בדוקר אנחנו מעדיפים לעשות copy-paste לפקודות בהן כולם משתמשים וכשמשהו נשבר מקווים שאחרי איזה ריסטרט הוא יתקן את עצמו. אני יכול לחשוב על שלושה מכשולים מרכזיים בגללם אנחנו מעדיפים לשמור מרחק ביטחון מהטכנולוגיה הזו- ## כי אתה לא יודע מספיק יוניקס המכשול הכי מרכזי לשליטה טובה בדוקר הוא יוניקס. כן, אותו יוניקס מפעם שבדיוק חשבת שהצלחת לברוח ממנו כשהתקנת את Docker Desktop על הווינדוס, הוא זה שבגללו אתה עכשיו מסתבך. קודם כל בגלל שרוב האימג'ים מריצים לינוקס, ולכן ברוב המקרים ה Dockerfile יכלול פקודות ריצה של לינוקס: התקנת תוכנות, הזזה של קבצים ממקום למקום, שינוי הרשאות. בלי להכיר את מבנה מערכת הקבצים בלינוקס ואת מנגנוני התקנת התוכנות מאוד קשה לכתוב ולתחזק Dockerfiles. סיבה שניה בגללה לינוקס הוא חבר חשוב בתהליך היא ה Entrypoint Script: כל קונטיינר מריץ סקריפט אחד מרכזי שנקרא Entrypoint, וברגע שהוא יוצא הקונטיינר נסגר. אימג'ים מעניינים כוללים סקריפטי כניסה מתוחכמים, וזה עוד משהו שצריך לתחזק ולדבג. והסיבה השלישית היא שאחרי שהקונטיינר עולה ומשהו נשבר צריך להיכנס אליו דרך ממשק שורת הפקודה, לבדוק את הלוגים ולהבין מה קרה. בלי היכרות טובה עם לינוקס וכלי עבודה משורת הפקודה קשה מאוד להתמצא ולמצוא את הבעיות. החדשות הטובות הן שהפיתרון לכל הבעיות מקטגוריה זאת הוא פשוט ללמוד יוניקס. יש אינסוף חומרי לימוד ברשת על יוניקס ולינוקס (גם פה באתר יש קורס), ולימוד לינוקס תמיד יהיה שווה את ההשקעה. ## כי אתה לא יודע מספיק על רשתות מכשול שני לשליטה טובה בדוקר הוא חוסר הבנה מספיקה ברשתות: מה זה DNS, מה זה פורטים, איך מקבלים כתובת IP, מה קורה אם למחשב יש כמה כרטיסי רשת, מה הקשר בין כתובות ה IP של הקונטיינרים לכתובת ה IP של המחשב שלי, מה זה Firewall, איך בודקים אם יש חיבור רשת בין כמה תחנות, מה עושים אם אין חיבור, ושאלות רבות נוספות בסגנון זה. אם אתם נתקעים כי הקונטיינרים שלכם לא מתקשרים אחד עם השני או עם העולם החיצון. אם אתם מסתבכים בחיבור הפורטים לקונטיינרים. אם אתם מדמיינים ארכיטקטורות רשת בין מכונות ולא יודעים איך ליישם אותן - תשמחו לשמוע שיש לכם בעיה של שליטה ברשתות. זאת בעיה יותר קשה משליטה בלינוקס בגלל שיותר קשה למצוא חומרי לימוד מסודרים. עיקר הלימוד יהיה דרך ניסוי וטעיה, ולכן אם אתם מזהים שזאת הבעיה שלכם כדאי דווקא כן לנסות לשבור דברים בדוקר וכן לנסות לפתור לבד כמה שיותר בעיות רשת, ודרך הבעיות ללמוד את הפיתרונות שרלוונטים לסוג העבודה שלכם. ## כי docker compose הוא באמת מבלבל מכשול שלישי נוגע לכמות החומר ולשכבות השונות של חומר על Docker Compose (ועוד יותר גרוע על קוברנטיס). דוקר קומפוז הוא כלי עבודה שכמעט כל מי שעובד בדוקר משתמש בו, הוא וותיק וה API שלו עבר שינויים לאורך השנים. לכן נוצר מצב שבכל חברה יש Best Practices שונים לגבי העבודה עם docker compose, וגם אם למדתם אותו לעומק בעבר הרבה דברים אולי כבר לא רלוונטים. לדוגמה מאפיין restart ב docker-compose.yml מגדיר איך להפעיל מחדש קונטיינרים, וגם מאפיין deploy.restart_policy עושה בדיוק את אותו דבר (אבל לכל אחד מהם תחביר קצת שונה והשפעה קצת שונה). אפילו אם החלטנו להשתמש בפורמט העדכני ביותר, עדיין יש אינסוף החלטות שצריך לקבל כמו האם להשתמש ב build או ב image, האם לקחת image מוכן ולהשתמש ב command או לבנות Dockerfile בעצמנו, האם לכתוב קובץ docker-compose.yml יחיד או קובץ נפרד לכל סרביס או קבוצה של סרביסים ועוד ועוד. הדבר החשוב לקחת כאן הוא ש Docker Compose הוא אוקיינוס. באמת יש המון דרכים שונות להשתמש בו במצב פיתוח וכל מקום עובד בצורה קצת אחרת. בשביל ללמוד טכנולוגיות כאלה כדאי לבחור Workflow אחד שמתאים לכם ולהישאר איתו לתקופה, ורק אחרי שאתם מרגישים ממש נוח איתו לחפש Workflow נוסף שיתאים לכם ואז להישאר איתו לתקופה. בעצם מה שחשוב זה להבין בכל פיצ'ר שאתם לומדים לאיזה שיטת עבודה הוא מתאים ואיך הוא משתלב הכי טוב באותה שיטת עבודה.

# אצלי זה עובד (טייק 319) אחת הסיבות שדברים נשברים בלי אזהרה מוקדמת היא יצירתיות של כותבי פריימוורקס (שלרוב לא מפורסמת בדף הראשי של הפריימוורק). הדוגמה היום היא מ Jest, ושימו לב ל Issue הבא: https://github.com/facebook/jest/issues/5818 ג'סט, למי שלא מכירה, היא ספריית בדיקות JavaScript שיכולה לשמש לבדיקות קוד צד שרת וגם צד לקוח. אחד הדברים החדשניים ש Jest עושה ישר מהקופסה הוא הרצה מקבילית, כלומר אם יש לכם מספיק בדיקות - ומספיק זו מילת המפתח כאן - ג'סט ינסה לארגן חלק מהן לקבוצות ולהריץ אותן במקביל כדי לחסוך לכם זמן. עכשיו אם יש משהו שהעולם לימד אותנו על לעשות דברים במקביל זה שהטריק הזה דורש מאמץ. רוב הסיכויים שאם כתבתם קוד "סתם כך" ואז התחלתם להריץ אותו במקביל אז משהו יישבר, ובמיוחד כשמדובר בבדיקות: מספיק ששתי בדיקות יוצרות קובץ באותו שם, או יוצרות מראש מידע זהה בבסיס הנתונים, בשביל שידרכו אחת לשניה על הרגליים. גם מתכנתים שיודעים שהבדיקות שלהם הולכות לרוץ במקביל עושים טעויות בכתיבת בדיקות כאלה. בחזרה לג'סט ול Issue שבקישור - מסתבר שג'סט יריץ את הבדיקות שלכם במקביל רק אם הוא חושב שיש מספיק בדיקות בשביל זה ושהבדיקות מספיק איטיות בשביל שבאמת תרוויחו משהו מהרצה מקבילית. הוא גם לא יריץ במקביל בדיקות שכתובות באותו קובץ בדיקה. אז אם אתם מתכנתים שכותבים קוד, כותבים קובץ בדיקה, מריצים את קובץ הבדיקה או כמה בדיקות קטנות ממנו ואז ממשיכים הלאה הכל יעבוד לכם כי הבדיקות רצות אחת אחרי השניה. אבל ברגע שתעבירו את הבדיקות ל CI להרצה אוטומטית, וה CI יריץ את כל סט הבדיקות תתחילו לקבל אינסוף כשלונות לא ברורים. הרצה ידנית של כל בדיקה שנכשלת או של קובץ בדיקות בודד תצליח בלי בעיה כי הכשלונות נובעים מאותה הרצה מקבילית שעובדת רק כשזה "משתלם". ג'סט לא לבד. הרצון של כותבי כלים לכתוב כלים שירוצו מהר ויתנו הרגשה טובה למתכנתים תמיד יחזור לתקוף אותנו במעבר לפרודקשן. שמרו על ערנות והיזהרו מכלים קלים מדי.

# מתי כן להשתמש ב mock ברוב הבדיקות שאני כותב אני בורח מ Mocks כמו מאש. הבעיות המרכזיות עם Mocks הן העבודה הנוספת שהוא דורש בכתיבת ה Mock ובתחזוקה, ואובדן האמינות בגלל שאני לא בודק את הדבר האמיתי. אבל Mock הוא לא לגמרי כלי מיותר ואני יכול לחשוב על שני מצבים בהם הוא אפילו הפיתרון המומלץ: ## בדיקת התמודדות עם שגיאות שימוש מומלץ ראשון ב Mock הוא בשביל לבדוק איך הקוד שלי מתמודד עם מצבים לא צפויים. תמיד אני מעדיף לבדוק מול ה API האמיתי כשצריך לבדוק התנהגות תקינה, אבל ב Flow רגיל אין לי דרך לגרום לשרת לחשוב שיש עליו יותר מדי עומס ולהתחיל להחזיר שגיאות. קוד בדיקה ב Jest יכול להפעיל:

global.fetch = jest.fn(() =>
  Promise.resolve({
    ok: false,
    status: 500,
    statusText: 'Server busy',
  })
);

ואז קוד רגיל שירוץ ישתמש ב fetch המזויף ותמיד יקבל שגיאת HTTP 500 במקום את התוצאה הרגילה, ואנחנו נוכל לוודא שהקוד מציג הודעה מנומסת למשתמש. ## התמודדות עם חוסר עקביות מובנה בבדיקה כשאנחנו בודקים קוד שהוא במהותו לא עקבי, ה Mock יכול לעזור לנו להתמודד עם חוסר העקביות הזאת ולגרום לקוד לחזור להיות צפוי. לדוגמה אם הקוד שלי מראה לוח שנה עם אפשרות לבחירת יום בחודש, ואני צריך שברירת המחדל תהיה היום הנוכחי. אז בלי Mock אני צריך להוסיף קוד שיבדוק איזה יום היום. עדיף לדרוס את Date לצורך הבדיקה ולגרום לקוד האמיתי לחשוב שאנחנו ביום מסוים. ב Jest זה יהיה:

jest
  .useFakeTimers()
  .setSystemTime(new Date('2021-01-01').getTime());