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

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

הי ינון, אנחנו מחפשים קורס Docker למתכנתים פה. הרבה חבר'ה עוזבים כי מרגישים שהמערכת שלנו מיושנת ולא נותנת להם כלים טובים להמשך. אנחנו עובדים על קוד PHP שנכתב במקור לפני 15 שנה ואין מצב להיכנס ל Refactoring בעתיד הנראה לעין אז אני די מבין אותם. בכל מקרה חשבנו לפנק אותם בקורס על איזה טכנולוגיה מודרנית שירגישו בעניינים. אפשר לשלב גם AWS, קוברנטס וכל מה שהולך היום. אם אפשר אחרי הקורס להמשיך לסידרת הרצאות העשרה על כל מיני Buzzwords זה יהיה מעולה. יש לך משהו כזה?

הי ינון, יש לנו מערכת PHP ישנה שכרגע אנשים די סובלים מהמשך תחזוקה שלה, ולאחרונה איבדנו כמה מהמתכנתים הטובים שלנו כי הרגישו שהמערכת גוררת אותם אחורה. אנחנו רוצים לעמוד חזרה על הרגליים ולתת פייט למתחרים שלנו ולכן החלטנו להתחיל שידרוג (איטי) לטכנולוגיית ענן בגישת Micro Services. אנחנו רוצים להתחיל להוציא התנהגות ומידע מהמערכת הקיימת ולממש אותם בתור Service ב Node.JS או Go, ומחפשים קורס שיעזור לנו עם המעבר. דוקר חייב להיות שם וגם הבנה טובה של ארכיטקטורת Micro Services. אם אפשר לקבל גם ליווי מקצועי אחרי הקורס בבניית הסרביסים הראשונים שלנו זה יהיה מעולה.

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

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

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

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

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

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

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

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

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

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

const winston = require('winston');
require('winston-syslog').Syslog;


// creates a new Winston Logger
const logger = winston.createLogger({
  level: 'debug',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.printf(({ level, message, timestamp }) => (
      `${timestamp} ${level}: ${message}`
    )),
  ),
  transports: [
    new winston.transports.Syslog({
      host: process.env.SYSLOG_NG_HOST,
      app_name: process.env.SYSLOG_NG_APPNAME,
    }),
  ],
});

logger.stream = {
  write(message, _encoding) {
    logger.info(message);
  }
};

module.exports = logger;

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

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

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

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

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

זה לא במקום, זה בנוסף.

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

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

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

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

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

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

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

export default {
  data() {
    return {
      value: 0
    };
  },

  methods: {
    inc(amount) {
      this.value += amount;
    }
  },

  render() {
    return (
      <div class="counter">
        <p>
          You clicked {this.value} times.
          <button onClick={this.inc.bind(null, 1)}>+1</button>
          <button onClick={this.inc.bind(null, -1)}>-1</button>
        </p>
      </div>
    );
  }
};

ואפשר לראות את מונה הלחיצות שלי בפעולה בקודסנדבוקס הבא: https://codesandbox.io/s/mystifying-leavitt-2iobe

הכתיב הזה בהחלט מרגיש בבית למתכנתי ריאקט. הכל פה חוץ מהשטויות של ריאקט, כלומר אנחנו כותבים class ולא className, ו for במקום htmlFor. בנוסף יש תמיכה גם ב Custom Directives של Vue, והכי מרגש שאפשר לכתוב את כל הקוד בקובץ js רגיל וכך לכתוב מספר קומפוננטות באותו קובץ. וכן למרות שהדוגמה שלי כאן היא מהכתיב הישן, גם Composition API תומך בסיפור הזה ומאפשר להחזיר JSX מ setup.

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

פרטים נוספים בתיעוד הקרוב אליכם בקישור: https://github.com/vuejs/jsx-next/tree/dev/packages/babel-plugin-jsx#readme.

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

קל לשאול "לאן נעלמה jQuery" או "מה קרה ל perl" ולתהות, האם קוברנטס עדיין יהיה רלוונטי בעוד חצי שנה? או React Native? ואפילו אם כן האם הם יהיו רלוונטיים באותו אופן, כלומר האם הגירסה שאני לומד עכשיו תהיה רלוונטית כשאני אגיע לרמה שאני יכול להשתמש בה כדי להרוויח?

אני חושב שהאמת קצת יותר מורכבת.

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

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

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

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

הייתי צריך להיות יותר זהיר ...

הייתי צריך להתאמץ יותר ...

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

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

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