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

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

1. חלק 1 - קומפוננטה ראשונה

2. חלק 2 - העברת מידע בין קומפוננטות

3. חלק 3 - תבניות דינמיות

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

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

1. את תראי גם איך להעלות את הסקין לאקסבוקס?

2. איך מפעילים מיינקרפט?

3. איך משחקים מיינקרפט?

4. את תראי איך למצוא סקינים באינטרנט?

5. זה עובד על Windows 10?

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

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

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

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

אם יש לכם Engagement ו Context, כל מפגש שתעבירו, בזום או בחיים האמיתיים, יהיה זמן שהושקע כמו שצריך.

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

1. בדיקות End To End בסביבת Micro Services הן הרבה יותר יקרות מאשר בסביבת מונולית (ולא שבמונולית הן היו זולות). עיקר העלות הוא הקושי להעלות מערכת מלאה ויציבה התואמת למה שיש בגירסת הפרודקשן.

2. למרות המחיר העצום, אם נצליח להקים תשתית של בדיקות End To End אלה הולכות להיות הבדיקות שיתנו לנו את הביטחון הגדול ביותר שהמערכת אכן עובדת. פה יש כל מיני טכניקות בתוך המשפחה שנקראת Testing In Production, כמו למשל לשכפל את סביבת הפרודקשן ולבדוק בעותק, או אפילו לייצר סביבה מקבילה (Shadow) לפרודקשן ולבדוק שם.

3. בעיות חדשות של E2E Tests לסביבת Micro Services: אין מי שיתחזק אותן, כי כישלון בבדיקה הוא תמיד חוצה צוותים; ושינויים מהירים במערכת מביאים לזה שהבדיקות מאוד לא יציבות. לכן בדיקות E2E יוצרות תלות בין צוותי, וזה בדיוק מה שרצינו לברוח ממנו כשהלכנו לכתוב Micro Services.

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

5. בכתיבת Component Tests לרוב נבצע Mock לסרביסים האחרים. פריימוורק בשם Pact מאפשר בצורה אוטומטית ליצור מתוך המוקים האלה מסמכי בדיקות עבור כותבי הסרביסים האחרים (הספקים שלנו) כדי שהם יוכלו להיות רגועים שהם לא שוברים לנו את הסרביס. בדיקות כאלה נקראות Contract Tests, ומסתבר שגם הן די יקרות לתחזוקה, אבל עדיין פחות יקרות מ E2E.

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

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

די בטוח שהיא לא האחרונה, וכנראה שהיא גם לא היתה הזדמנות.

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

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

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

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

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

1. חלק 1 - קומפוננטה ראשונה ב Vue

2. חלק 2 - תקשורת בין קומפוננטות

שתי התכונות הבאות מאפיינות הרבה מהמתכנתים הטובים שפגשתי:

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

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

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

אפשר ושווה להתאמן על זה.

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

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

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

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

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

שתי דוגמאות קלות ומסקנה -

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

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

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

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

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

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

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

ספליטגייט פירסמו התנצלות לפני מספר ימים בחשבון הטוויטר שלהם בזו הלשון (תרגום שלי):

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

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

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

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

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