יום שני, 24 בפברואר 2020

386 Building internal products

פודקאסט מספר 386 (מתקרבים לפנטיום?) של רברס עם פלטפורמה - אורי ורן מארחים בכרכור (בלי משקפיים) את תומר מחברת Natural Intelligence לשיחה טבעית על העיקרון של מוצרים פנימיים של חברה (שנועדו לשמש את החברה עצמה) - מתי נכון לקנות מוצרים כאלה ומתי נכון לבנות אותם (Build/Make vs. Buy).

קצת על תומר
  • בן 37, גר בתל אביב, נשוי + 2 - והיום VP Product ב - Natural Intelligence, כמעט שנתיים בחברה.
  • לפני כן כמה סטארטאפים קטנים יותר, בעיקר באיזור החיוג של Cyber Security, Analytics, Data
  • היום ב - Natural Intelligence מתעסק בעיקר בעולמות של המוצרים הפנימיים ופחות בעמודי האינטרנט שהם Consumer-facing, יותר בכיוון ה-Back-office.
למעשה הנושא של Build vs. Buy הוא “בדמך” . . .
  • לגמרי - ובשנה האחרונה זה בשיא.

קצת לגבי מה אתם עושים . . .
  • החברה Natural Intelligence לא לגמרי צעירה - קיימת כבר למעלה מ-10 שנים, מעל 450 עובדים.
  • מפעילים מאות אתרי השוואות שהמטרה שלהם היא לעזור לצרכנים מכל רחבי העולם לקבל החלטות נכונות יותר לגבי שירותים שונים, בדרך כלל שירותי Online.
    • החל מהשוואות לשירותי ביטוח דרך Home improvements, פיננסים, שירותי B2B - כמעט לכל ורקיטל שיש לו “Service on a Click” אנחנו נביא ל-Consumer את ה - “Top 10 options” באיזור חיוג שלו כדי לעזור לו לבחור - זה בעצם מוצר ה-Consumer-facing שלנו.
    • יש עולם מוצרי שלם עם Roadmap משלו מאחורי זה, שמאפשר את כל האופטימיזציה של החווייה הזו - ה-Data וה - A/B Testing וה - User acquisition וכו’ - וזה ה-Roadmap שאני מנהל ביחידה שלי.
אני מניח שלפחות את חלק מהאתרים האלה אנחנו ראינו - ואולי אפילו לא ידענו שזה מה שאנחנו רואים . . . איך זה נראה - כמו בלוג-פוסט שמישהו לכאורה כתב? איך נראה אתר כזה?
  • שאלה טובה . . . גם וגם.
  • בהרבה מאוד אתרים שלנו יש דוגמא טבלאית בצורה כזו או אחרת.
  • חלק מהאתרים הם Non-branded - למשל אם תחפש VPN ותגיע ל-”Top 10 options for VPN” באיזור ניו-יורק או איפה שלא תיהיה.
  • חלק מהאתרים הם כן Branded - ואז זה יופיע בצורה של טבלה או כתבה או בלוג שמשווה כמה אפשרויות טובות עבור אותו שירות.
  • הקוספט בסוף הוא אותו הדבר - לזקק עבור הצרכן כמה אופציות טובות שרלוונטיות אליו - למיקום הגיאוגרפי, למגדר או לכל מאפיין אחר שלו.
מי הם הלקוחות?
  • היום יש בעצם שני סוגי לקוחות, כשאנחנו רואים את זה כמעיין משולש - אנחנו ועוד שני פרטנרים:
    • שותף ראשון הוא הצרכן - משתמש הקצה, שלא משלם לנו אבל הוא זה שנהנה מהחוייה ומהאתר
    • שותף שני הוא הלקוח המשלם - אותם Brands שנמצאים אצלנו בתוך האתרים - כל מותג עם הסיפור העסקי שלו - הרבה מאוד Deals וסיפורים עסקיים שונים.
    • אחד האתגרים שלנו, לפחות בצד של ה-Business, הוא לאזן את המשוואה בין טובת ה-Consumer לבין ה-Business, שצריך להחזיק את עצמו.
אני מניח שהתוכן הזה מיוצר (מג’ונרט, Generated) בצורה בעיקר (אם לא רק) אלגוריתמית, ובעצם המהות של זה היא נושא מעניין לפודקאסט - לא על זה נדבר היום, אבל אני מניח שיש מאחורי זה טכנולוגיה עמוקה ומעניינת ששווה לדבר עליה בהזדמנות.
  • לגמרי . . . אפשר גם לנחש מהו מקור השם בהקשר הזה . . .

מה שאנחנו כן הולכים לדבר עליו זה יותר זה החלק שהזכרת קודם של ה - Back office: כל אותם מוצרים שגורמים לכל זה לפעול, מעיין “מערכת ההפעלה של החברה”.
בכל חברה מגודל מסויים יש סט כזה של מוצרים - החל מ-Dashboards פנימיים דרך מערכות לניהול קמפיינים (שתכף נדבר עליהם) ועוד - יש לא מעט כאלה.
איפה התחלתם לפגוש את הנושא הזה? היכן הגיע המפגש הראשון שלך עם הדילמה הזו של Build vs. Buy?
  • המפגש הראשון היה בתרגיל בראיון שעשו לי כשהגעתי לחברה . . . התרגיל היה “שרטט על הלוח איך נראה ה-ETL של ה - Data Pipeline, ה-Revenue Data של החברה - עד שבסופו של דבר Business user יודע לצרוך אותו.
  • בעצם ב-Sub-text נאמר שיש פה איזשהו מוצר שקנו לפני כמה שנים - מעיין Drag&drop GUI שמאפשר לבנות ETL “ללא מפתחים”…
  • איך קראו לזה? נדלג, חברה ישראלית לשעבר . . . יש לא מעט בתחום אז קשה לנחש, אבל בסדר.
  • בעצם אותו Drag&drop פשוט וקל להפעלה, שיהיה כמובן “מאוד אינטואיטיבי וירקיע שחקים יחד עם החברה” הפך פתאום לאיזשהו Bottleneck מאוד משמעותי
  • מאחר וזה ממש ב-Core של ה-Infrastructure,יש הרבה Processes אחרים שתלויים בזה ויש המון מוצרים עם אינטגרציה על זה - וזה הפך ל-Showstopper.
מה היה גודל החברה בשלב הזה?
  • היינו עם Business די דומה בגודל, הרבה פחות אנשים - סדר גודל של כ-250 - אבל כבר אז זו הייתה בעיה קשה.
וכשהתחילו להשתמש באותו המוצר - מה היה גודל החברה?
  • הרבה פחות . . .
סביר שזה מוצר שאולי גם היום טוב עבור חברות קטנות, אבל כשהגעתם לסדר גודל של כ-250 עובדים המוצר כבר לא החזיק מים . . .
  • יכול להיות שזה באמת היה טוב בזמנו, אבל באיזה שלב אתה צריך להסתכל ולהגיד לעצמך “זה כבר לא משרת אותי”.

(אורי) העולם הזה, של כלים פנימיים - יש בו שני דברים: הראשון הוא גדילה (אתה גדל, יש יותר עבודה וצריך לפתח יותר כלים ואוטומציות כי יש יותר אנשים שיכולים לעשות טעויות); השני הוא (לפחות בחווייה שלנו ב-Outbrain) שיש Domain עסקי מסוים “שיושב” אצל איזשהו צוות והאנשים באותו צוות מתחילים לפתח גם כלים.
  • הם מפתחים את הכלים וחוזרים להתעסק ב-Domain העסקי שלהם ובלהזיז אותו קדימה.
  • האופרציה מתחילה להשתמש בכלים - כשלאט לאט הכלים האלה הופכים למעיין “בן-חורג” - והם תמיד הדבר האחרון שמתייחסים אליו כשבונים Roadmap או תוכנית עבודה
  • (רן) ומחלידים . . .
  • (אורי) לגמרי - עד שלב שהם הופכים ללא-שמישים, כי אתה גדל כל הזמן ואף אחד לא מתחזק אותם, והם לא מצליחים לעמוד בעומס.
  • (רן) לפעמים אתה עושה טובה ונותן לסטודנט או לעובד החדש בצוות לתחזק אותם - ולפעמים גם זה לא.

אז הוצגת (תומר) בפני השאלה של בניית ETL - ואז התקבלת לעבודה ואמרו לך “אוקיי, בוא תבנה ETL”?
  • לשמחתי לא אני בונה את ה-ETL אחרת הייתה קטסטרופה, אבל בהחלט התחלנו לאפיין את כל ה-Infra החדש של ה-Data ETL שלנו מ-Scratch.
  • כמעט כל השנה שעברה הוקדשה ל”להרוג את הייצור הזה שהבאנו” ולהשתמש במוצר שמפותח פה.
    • כזה שמתאים ל-Scale, ל-Business case, ל-Time-To-Market שאנחנו נדרשים אליו מה-Business users, כדי לייצר pipeline חדש של Data-source חדש.
    • מאז אנחנו נתקלים בשאלה הזו בהמון מקרים…

ואם נסתכל רגע שוב על אותו מוצר - זה היה לפני שנתיים? מאז למעשה כבר כל החברה עברה Migration? כל ה-ETL עברו לשם?
  • כן.
ובראייה לאחור - אם היית עכשיו מתחיל מאפס, בהסתכלות על מוצרים אחרי שיש בחוץ - היית עושה את אותו הדבר, או שאולי בכל זאת היית בוחר במוצר חיצוני במקרה הזה? האם בשלב הזה בדקתם מוצרים חיצוניים אחרים? אולי Open-sources?
  • בשלב הזה ידענו שאנחנו רוצים לעשות משהו שיותאם מאוד ל-Use-case שלנו ולמבנה העסקי שלנו, שכלל לא רק ETL
  • היה בזה גם מוצר יותר גדול שכלל אוטומציה מלאה של כל ה-Funnel של Revenue Data
  • זה מורכב כיוון שה-Revenue לא נוצר אצלנו אלא אצל ה-Brands שמופיעים אצלנו ב-charts - אני צריך לגשת לכל אחד מ(מאות) הלקוחות ולהביא מהם את ה-Conversions וה-Commissions ולהזרים את זה אלי.
  • זה היה חלק ממערך גדול יותר, שהבסיס שלו היה איזשהו ETL שעד אותו רגע היה תקוע במוצר שכבר לא כל כך ידעו איך להשתמש בו.

(רן) אני חושב שהרבה חברות באות עם גישה של “אוקיי, אז אנחנו עכשיו צריכים משהו - אם זה ב-Core שלנו אז נפתח את זה אנחנו; אם זה לא ב-Core שלנו, אנחנו נקנה את זה” - וזה אולי נשמע טוב על הנייר רק שהשאלה הראשונה כאן היא האם זה באמת ב-Core או לא? 
  • למשל - האם ETL זה חלק מה-Core? יש הרי ETL מהמדף, אבל אם כל אחד מהם שניסינו מאט לנו את ה-Business - גם אם זה לא ב-Core, זה הופך ל-Core . . .
מתי נפל האסימון בחברה ש-ETL זה אולי לא המוצר שלנו אבל זה מה שמניע את ה-Core ולכן אנחנו חייבים לפתח את זה?
  • אנ חושב שזה בדיוק בשלב של הבגרות של החברה שבו היא מתחילה לגדול, ואז היא מבינה שה-Scale הוא כבר דרישה דרמטית.
  • חברה קטנה שמתחילה - כל המשאבים שלה והפוקוס הפיתוחי והמוצרי חייב להיות במוצר, וחייבים להשקיע בלקוחות הראשונים ובמשקיעים הראשונים, אין את הלוקסוס להשקיע “בפריפריה”.
  • כשהחברה גדלה, ויש לה כבר את המוצר הבסיס עומד ואין כבר לחץ של משקיעים (?) ולחץ של לשמור את חמשת הלקוחות הראשונים באוויר - הזה זמן להתחיל לדאוג למה שיקרה בעוד שנה או שנתיים מהיום
    • איך אתה תומך ב-Scale יותר גדול, ביותר לקוחות, ביותר משתמשים פנימיים

(אורי) כשאני מדבר על זה עם יזמים - על Build vs. Buy - אני אומר להם “תזכרו תמיד שמתישהו תצטרכו לבנות, ותראו שאתם לא מפחדים להביא את הידע” - הרבה פעמים מפחדים לבנות כי אין את הידע - אבל הנקודה להתחיל להתעסק בדברים האלה היא הנקודה של Product-Market fit.
  • עד ה - Product-Market fit אתה קטן ואתה לא עושה Scaling וחשוב לך להיות מהיר כמה שיותר ולהתעסק ב-Core שלך כדי להגיע לאותו Product-Market fit.
  • ברגע שהגעת לשם - יאללה, צריך לתחיל לחשוב על כל אותם דברים שהם Scale, וזה נוגע קודם כל ל-Scale הטכנולוגי (שבכלל יהיה אפשר לעשות את זה) - ולעלויות . . .
  • (רן) מאוד מתאים למה שתומר אמר קודם - שהחברה נתקלה באתגרי scale והחליטה שה-ETL הקיים לא מתאים יותר.
  • וקצת לאתגר אותך (את אורי) - השותף שלך ב-Outbrain - ירון - אמר פעם שנכון שיש Product-Market fit, אבל זה אף פעם לא סוף המשחק: עכשיו מחפשים את ה Product-Market fit הבא, וכל הזמן עושים על זה איטרציות.
    • זה לא שיש נקודה שבה אתה קם בבוקר ואומר : “יופי, הגרפים מתחילים לעלות, יש Product-Market fit!” - זה חיפוש מתמיד.
  • (אורי) נכון - אבל בשלב מסוים אתה מתחיל לגדל Core Business שמתחיל להוות “פרה חולבת” שהולכת ומשמינה (זו התקווה), ואם אתה לא תטפל בדברים שקשורים ב-Scale, אתה תעצור את ה-Business הזה.
  • אתה צריך להיות מסוגל לתמוך בגדילה הזו של ה-Core, וכמו שירון פעם אמר לי: “אנחנו כבר חברה מספיק גדולה, כבר יכולים ללכת וללעוס מסטיק ביחד”.
    • יש לנו את ה-Core שימשיך לגדול ולעבוד, אבל אנחנו צריכים להיות מסוגלים לפתח גם את הכיוונים הבאים ולעבוד עליהם בצד.
  • (תומר) באיזשהו שלב פשוט ה-Core מתרחב עם הזמן - התפיסה של מהו Core ומהו Enabler להצלחת החברה הבוגרת, שכבר אינה סטארטאפ קטן, הולכת ומתרחבת.
    • הרבה דברים הם Enablers על מנת להמשיך ולגדול למדרגה הבאה.
  • (אורי) בהרחבות של Core, אם לצורך העניין יש לך סט Features בסיסי של המוצר - עכשיו כשאתה מביא את הפיצ’ר הנוסף, הוא לא כמו בפעם הראשונה כשבנית אותו עבור חמישה לקוחות ויכולת לעגל פינות באתגרים של Scale - עכשיו כשהפיצ’ר הזה יצא לשוק, הוא יצא למאות ואלפי לקוחות.
    • פיתוחים ב-Core - צריכים להבין שהם מביאים איתם עוד משהו - זה לא Tech-debt אלה מעיין enablement . . . “אתה כבר צריך לחיות ב-Scale”
    • (תומר) סוג של Biz-Debt - משהו שהוא כבר חלק הכרחי של ה-Business.
  • ויש עוד שאלות בהקשר הזה (של תומר), למשל - A/B Testing: האם כלי לניתוח A/B Testing צריך להיות חיצוני או פנימי? אני חושב שחברה שרק מתחילה את דרכה בעולם ה-Online כנראה שתשתמש באיזשהו כלי חיצוני שזמין לה, כי יש לה דאגות אחרות על הראש (Google Analytics למשל).
    • תוך כדי העבודה ב-2019 על ה-Roadmap, כשאמרנו שאנחנו צריכים לבנות כזה כלי והשאלה הייתה האם לבנות או לצאת החוצה, היינו כבר בתפיסה שזה חלק מה-Core של העבודה
      • האופטימיזציה וכו’ - זה חלק מה-Core.
      • לפני 6-7 שנים זה אולי לא היה ברשימת הדברים שהם חלק מה-Core של המוצר.
  • (רן) אתה אומר שאולי לפני 6-7 שנים זה לא היה חלק מה-Core אבל ההגדרה של ה-Core הולכת ומתרחבת וגם את זה צריך לקחת בחשבון.

דיברנו קודם על מקרה שבוא היה מוצר שקניתם ובסופו שלדבר החלטתם לבנות - האם היה לכם גם מקרה מהסוג ההפוך, של מוצר שבניתם והחלטתם שאתם רוצים להפסיק לבנות והחלטתם לקנות?
  • אנחנו עכשיו בהתלבטות כזו, עם משהו מאוד פשוט - פונקציונאליות של Fetching, מה-API החיצוניים אל תוך ה-Data Lake שלנו.
  • פיתחנו Fetcher פנימי, in-house, שניגש לכל מיני מקורות מידע - אם זה Marketing channels או הלקוחות שלנו - והביא את ה-Data בקבועי זמן כלשהם.
  • אנחנו נתקעים שם בבעיות של Time-to-Market - ה-Business unit רוצה מידע בקבועי זמן מסויימים מ-Channel חדש (נגיד Outbrain לצורך הדוגמא) - ועכשיו אני צריך להשקיע בזה אנשי פיתוח ו-Engineering, שלא יעשו משהו שתואם לליבה העסקית אלא ב-Fetching ל-API.
    • וזה - כשיש כלי מדף שזה בדיוק מה שהם עושים, וגם אנשים שהם לא חלק מה-Engineering ואולי יותר זמינים (Availability) יוכלו לעשות איזשהו Drag&drop, יתחברו ל-API וזהו.
    • בימים אלו אנחנו מתלבטים האם לעשות סוג של “אחורה פנה” ולהתחיל להביא Data מסויים באמצעות כלי שלישי ולאו דווקא באמצעות כלי Fetching שפיתחנו בעצמנו.

דיברנו על שתי דוגמאות, עכשיו ננסה לעשות הכללה, לראות מה הם הקווים המנחים ואיך אתה מחליט . . .
  • הראשון היה “האם זה ב-Core או לא?”
אילו עוד פרמטרים אתה לוקח בחשבון כשאתה מתלבט האם לבנות מוצר פנימי או לקנות משהו?
  • אני חושב שהצלחנו לגבש כמה שאלות שמנחות אותנו בתהליך ההחלטה או ה-Evaluation של הצורך שעלה מה-Business או הצורך הטכנולוגי שלנו.
  • אחד מהם זו באמת שאלת ה-”Core או לא”’  וגם עד כמה ניהיה “נעולים” לתוך אותו מוצר - כמה שכבות של Processes או מוצרים אחרים “יתלבשו” עליו, ואז אני נשאר עם איזשהו 3rd-party שתקוע בליבה של שנים קדימה.
    • מה  שקרה לנו בעולם ה-Data…
    • (רן) אתה קונה אוטו, ומרכיב עליו גגון - ועל זה יש אוהל, וסככה וכו’- ואז כשאתה רוצה להחליף את האוטו, אתה מגלה שזה לא גנרי, ואי אפשר “סתם” להחליף את האוטו.
    • (תומר) או שהמחיר של החלפת האוטו הוא כל כך יקר שזה פשוט מגוחך.
    • (אורי) אבל הסיכוי להחליף אוטו, שבדרך כלל יש לו ארבעה גלגלים, וגג וחיבור סטנדרטי לגגון . . . הסטנדרטיזציה במוצרי מדף תיהיה יותר גבוהה ממה שאתה תבנה בפנים.
  • (תומר) זו בדיוק השאלה השלישית - האם ה-Business case שלי הוא ייחודי לי או שהוא גנרי מספיק? האם יש איזשהו צורך שכנראה עדיף לי לפתח In-house את המענה אליו, או שזה use-case שיש להרבה חברות כמוני ולכן אין סיבה להתמודד עם זה מאפס, ועדיף לקחת משהו שקיים בחוץ - כמו Fetching.
  • (רן) … או A/B Testing - כל החברות עושות זה. האם הצרכים שלי ב-A/B Testing דומים לשאר החברות? אם כן אז סביר להניח שאני אמצא מוצר מתאים, אבל אם הצרכים שלי מאוד ייחודיים אז חבל לחפש כי כנראה שלא אמצא משהו מתאים ועדיף כבר לפתח בפנים.
  • (תומר) כן - ושאלה שמתחברת לזה היא לא על הייחודיות שלה-Business case אלא על הייחודיות של ה-Best Practice אצלנו בחברה, בעיקר באוטומציות.
    • כשאנחנו באים לאטמט (To Automate, ל”עשות אוטומציה”) תהליכים ידניים של Back-office או של Business או אופרציות כאלו, אנחנו תוהים האם יש לנו איזשהו Best Practice שאנחנו צריכים לשמר אותו על ידי פיתוח פנימי.
    • נתקלנו בזה המון תוך כדי אוטומציה של user acquisition למשל, בעיקר Bidding מול Ad-words או Bing Ads  -איך אני מאטמט את תהליך ניהול הקמפיינים? האם אני לוקח איזשהו כלי חיצוני (ויש המון כאלו שמאפשרים Bidding אוטומטי), או שאני מפתח פנימית?
    • שם, החלטנו שבכל המקרים באמת החברה התמחתה לאורך השנים בכל מיני תהליכים של user acquisition ששווה לחקות אותם באופרציה הפנימית שלנו ולא להסתמך על כלי חיצוני.
  • (רן) זאת אומרת שיש מעיין Business-Intelligence, הרבה חוכמה (know-how) שאולי לא ”קודדה” עד עכשיו, אבל שווה לקחת את הזמן ולקודד אותה כי סביר להניח שזה לא משהו שתמצא מבחוץ.

אילו עוד פרמטרים אתה לוקח בחשבון?
  • הכל מתחבר אחד לשני . . . Time-to-Market זה גם משהו שאנחנו שואלים את עצמנו - האם יש לי בכלל שיקול Time-to-Market דרמטי בסוגייה? יכול להיות שזה צורך שהוא חשוב אבל לא כל כך דחוף, או שזה צורך דחוף ולכן “מחר בבוקר” צריך להעמיד איזשהו פתרון - ואז השאלה היא מה יהיה יותר מהיר: פיתוח של שני אנשים “בתוך הבית”  שיכולים לרוץ מהר או דווקא אינטגרציה עם חברה חיצונית שאולי תיהיה יותר מהירה.
    • (אורי) יש Time-to-Market ויש Time-to-Scale - המקום של כלים פנימיים מגיע הרבה פעמים ביכולת לאפשר Scale.
    • אני יכול להגיע לשוק ולפעמים אני רוצה להגיע לשוק ולבדוק משהו, לאו דווקא כדי לרוץ ולשווק אותו - אז עבור חמשת הלקוחות הראשונים, על מנת שיהיה משהו לבדוק, אני יכול גם לאפשר מצב שבו אנשים יעשו משהו בידיים, סוג של POC, ובשביל זה אני לא אבנה כלים.
    • כשאני מתחיל לחשוב אח”כ איך אני עושה לזה Scale, ברור שאי אפשר להעמיד צבא של אנשים שיעשו הכל ידנית.
  • (תומר) התלבטות נוספת שאנחנו מתלבטים איתה ממש בימים אלו היא שעד היום רוב התקשורת מול ה-Brands שנמצאים אצלנו באתרים נעשתה ע”י אנשי ה-Business בדרכים שגרתיות של מיילים, טלפונים וכו’ - והחלטנו שאנחנו רוצים להעביר את כל התקשורת הזו לאיזושהי פלטפורמה מנוהלת מודרנית.
    • סוג של CRM? אולי Marketo? יכול להיות, אבל יש לדוגמא גם מוצר שעליו הסתכלנו בין היתר של Salesforce בשם Communities, שהוא משלים ל-CRM ומאפשר את התהליך של user-login-כניסה, אפשר לצפות בביצועים שלו, באילו אתרים שלנו הוא נמצא, לראות Performance dashboard שלו - וכמובן אפשרות לצ’ט עם ה-Account Manager שלו וכן הלאה
    • זו מעיין פלטפורמה שתיהיה חלק עיקרי בתקשורת שלנו מול הלקוחות וגם כאן יש שאלה - ברור שאם אני אקח כלי חיצוני, Salesforce לדוגמא - מחר בבוקר אני יכול יחסית בפשטות להביא כלי שעובד, אבל השאלה האם בטווח הארוך זה לא חלק דרמטי מהיחסים שלי עם ה-Business? האם יש כאן איזשהו use-case מאוד ייחודי שאני צריך לתמוך בו, מעבר לרק התצוגה של המידע?
    • אנחנו בדיוק בשלב הזה של לאפיין בדיוק מה גם, שלוש שנים קדימה, הולך להיות השימוש של אותו אמצעי תקשורת - ומכאן לגזור האם כדי להביא כלי מבחוץ או לפתח בפנים - וזה אומר מאפס, כי היום אין לי שום תשתית לזה - 
      • להביא אנשי פיתוח, Frontend, Backend, Designers וכו’.

(רן) וזה מביא אותנו לשיקול הבא - כוח אדם (או תקציב או איך שלא תסתכל על זה) זה מן הסתם שיקול משמעותי.  היום ב - Natural Intelligence אתה יכול להגיד מהי מצבת כוח האדם של אנשים שעובדים רק על מוצרים פנימיים? או כאיזשהו אחוז מכוח האדם?
  • אצלנו ביחידה שעובדת בעיקר על מוצרים פנימיים מדובר על סדר גודל של כ-80 אנשי פיתוח, אולי 65 בלי אנשי מוצר, רק לכלים פנימיים.
    • זה Data ופלטפורמת תוכן, אוטומציות . . . כל זה פחות או יותר
אנחנו מדברים על מוצרים פנימיים, לא תשתיות (ענן, Databases וכו’)?
  • תשתיות כמו Data Lake למשל כן נכלל בזה מבחינתי, ה-ETL גם.
קבוצה גדולה . . .
  • כן - קבוצה גדולה, והיא גדלה בעיקר בשנה וחצי האחרונות גדילה די מטורפת, כי החברה הגיעה לאיזשהו שלב בגרות שדורש אוטומציה ו-scale הרבה יותר רחב על מנת לתמוך ב-Business
  • וזה כמובן מעלה שאלה של Cost - איפה כדאי להשקיע את הכסף: בקניית מוצר או ב-Headcount ולפתח אותו פנימית?
(אורי) אמרת “80” ואני הגבתי ב”וואו!” - כי ב-Outbrain הצוות שמוגדר עבור כלים פנימיים הוא 5-6  - אבל קל כביכול לשכוח שיש את כל מה שאנחנו מכנים “MIS” - כל ה-Salesforce וה-Marketo וכל הכלים שנמצאים שם והחיבוריות ביניהם והחיבוריות שלהם למוצר עצמו ול-Dashboards של המוצר עצמו
  • (תומר) שאצלנו זה חלק מהמוצרים הפנימיים - כל ה-Visualization של הנתונים והבאת ה-Data ל-RedShift  כדי שיהיה זמין ל - Business user . . .
  • (אורי) מה שלפעמים מכנים “BI” או Dashboards  . . . וואלה, אם אתה כולל בפנים את כל הדברים האלה, ב-Outbrain זה כנראה אותו סדר גודל.
    • (תומר) הייתי שמח לשמוע שיותר אפילו . . .  מעניין.
  • ועדיין - גם כשגדלים זה בטוח לא אומר שצריכים להיות “קלים על ההדק” מבחינת הכנסת פיתוח של דברים ל-Roadmap.
  • למשל Email Marketing - למה לפתח את זה פנימית? בדיוק עכשיו החלטנו לסגור עם איזשהו Vendor חיצוני, אין שום צורך לפתח משהו שהוא לגמרי סטנדרטי וגנרי - פנימית. 
    • עדיף להביא משהו מבחוץ וזו דוגמא למשהו כזה.
  • (אורי) גם את ה-CRM של החברה לא . . . זה משהו להביא מבחוץ, וגם לא את ה-ERP של החברה. יש עוד ראשי-תיבות של 3 אותיות?
    • אולי IDF . . . נשק זה משהו שכדאי לפתח פנימית? נושא לפרק עתידי עם רפא”ל.

לקראת סיום - משהו שרצית לכסות ועוד לא כיסינו?
  • רק את המובן מאליו - בסוף, אחרי כל ההחלטה על פנימי מול חיצוני, יש את ההערכה עצמה של הכלי, כלומר - כמה הוא עולה? למה הוא טוב? מה חברות דומות לי עשו ובאיזה כלי הן בחרו? האם הכלי תומך ב-Scenarios שאני אדרש להם חמש שנים קדימה?
    • לפתוח עוד Spreadsheet של Evaluations . . .
    • (רן) אתה מכיר איזשהו אתר השוואות שיכול לעזור?

לסיכום - 
  • דיברנו על העיקרון של Build vs. Buy, עם כמה דוגמאות מהחיים ב - Natural Intelligence
  •  ניסינו להפיק כמה Rules of thumb על איך נכון להחליט - מהם הפרמטרים -
    • האם זה חלק מה-Core?
    • האם יש סכנה של Vendor Lock-in?
    • האם יש Unique business case או איזשהו “secret sauce” של החברה?
    • יש גם Time to Market כמובן

היה מעניין, תודה תומר. איפה אתם יושבים? מחפשים אנשים?
  • ברור - משרדים הורסים ב-ToHa בתל אביב, אי שם בפריפריה שאחרי איילון
    • לא, כי כרכור . . . :-)
  • מגייסים כל הזמן - בואו בהמוניכם: מפתחים, אנשי Product - בואו.

הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

יום ראשון, 23 בפברואר 2020

385 Bumpers 65

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

רן - 
  • חברת Shopify (חברת eCommerce קנדית) מציגה קונספט מעניין של Dev Degree: מציעים למפתחים בתחילת דרכם (לפני השלמת התואר) לעבוד אצלם, כשהם הם מממנים את הסיפור הזה.
    • שיתןף פעולה עם כמה אוניברסיטאות באיזור, כשהסטודנטים לומדים ועובדים במקביל, במימון החברה.
    • עוד סינגל לכך שחברות צמאות לכוח אדם ומוכנות לשלם הרבה עבור זה - גם בכסף וגם בזמן - Internship מאוד ארוך, במקרה הזה של 4 שנים.
    • בעיית כוח האדם קיימת בכל העולם ומעניין לראות פתרונות יצירתיים - יש הרבה תוכניות של העסקת סטודנטים אבל זה בהחלט די קיצוני.
    • מעניין אם יוזמה כזו תוכל להתרומם גם בישראל.
  • אחד השחקנים המובילים של Go - איש בשם Brad Fitzpatrick - עוזב את Google ולמעשה עוזב את ה Core Development Team של Go.
    • מדובר במפתח עם הרבה מאוד קרדיט בעולם של Go וגם הרבה לפני כן.
      • משתמשים ב Memcached? אז זה קוד שלו מאחת החברות הקודמות.
      • כתב עוד לא מעט מערכות מבוזרות מעניינות.
    • עכשיו החליט שהספיק לו - אחרי 12 שנים וחמישה חודשים . . .
    • הבלוג כולל עוד כל מיני סטטיסטיקות מעניינות שהוא אסף על התקופה הזו - Commits, Code reviews ועוד.
    • אחד האנשים שכתב הרבה מהסביבות הפנימיות, ומשאיר את ה-Community במצב מאוד טוב ובריא - אומר שיהיה נחמד להשתמש בשפה ולא רק לפתח אותה.
    • מצד אחד עצוב, מצד שני מגיע לו הרבה קרדיט על תרומה משמעותית.
  • ולענייני Security - רן קיבל לפני כמה שבועות שיחה מעניינת ממספר פרטי . . .
    • שיחה באנגלית, לא נשמע בריטי או אמריקאי, מבטא כבד . . . נשמע כמו התחלה של שיחה על כנס כלשהו.
    • הדובר עדכן על כך ש”מחשב ה-Windows” ככל הנראה נפרץ ומבצע “פעילות חשודה”. האדם שהתקשר אמר שהוא “מטעם Windows” וביקש לבצע מספר פעולות.
    • בהתחלה נשמע הזוי ו”על מי מנסים לעבוד?” - ומצד שני אולי יהיה נחמד לשחק עם זה קצת… לא שווה את השיחה?
    • רן המשיך ומדי פעם שאל שוב מהיכן מגיעה השיחה (מה זאת אומרת? “מ-Windows!”, בסיאטל…)
      • מישהו ב-Microsoft כנראה היה עונה Redmond
    • “איך אתה יודע שהמחשב שלי?” - “הוא רשום על שמך”. מוזר, לא היה כנראה מחשב Windows רשום על רן כבר הרבה שנים…
    • ואז היה צריך לגשת לאיזשהו אתר - ואז הגיעה שיחה אחרת יותר חשובה והיה צריך להפסיק את המשחק.
      • כנראה שהשלב הבא היה להוריד משהו ולהריץ אותו - ואז אכן המחשב יהיה פרוץ. סוג של חיזוי עתידות…
    • לעיניינו - השקעה די מרשימה: מצאו שם וטלפון, חייגו מחוץ לישראל (לא בטוח - בהמשך האייטם)
      • האם זה משתלם? מה אחוזי ההצלחה ומה עושים עם זה?
    • (דותן) קרה לנו מקרה דומה לפני שנה ולפני שנתיים - ותמיד אלו היו שיחות אל מישהו שמתעסק ב-DevOps או Infrastructure או משהו קשור - יכול להיות שמטרגטים מקצועות?
  • ולמשהו יותר חמור - פוסט של רן בר זיק, שבו הוא מתאר את הכשלים שהיו באפליקצית אלקטור
    •  היה הרבה בחדשות, אז רק תקציר - מדובר באפליקציה שנמצאת בשימוש מפלגת הליכוד על מנת לנהל את הקמפיין ולהיות בקשר עם הבוחרים
      • מדובר במעיין פורטל / אפליקציית ווב שבמאגרי המידע שלה יש גישה לכל מאגר הבוחרים בישראל - משהו כמו 6.5 מיליון אזרחים, כתובות מספרי טלפון . . .  כל זה כל כך קל לפריצה שזה די גובל בפשע.
      • שימוש בכלי הפריצה “דפדפן”, כפתור-ימיני View source ומשם מהר מאוד אל סיסמאות ה-Admin . . . זה ספציפית כבר לא קיים (?), אבל כנראה היה פתוח לא מעט זמן ואפשר פשוט להוריד את כל פנקס הבוחרים של ישראל.
      • יש על זה כמובן פרק ב-CyberCyber - האגרון 2: פנקס הבוחרים המלא דלף לרשת דרך הליכוד
    • אולי משם הגיעו הפרטים של רן מהאייטם הקודם?
    • בכל אופן, רמת החשיפה של כל אזרחי ישראל הרבה יותר חמורה כרגע, כולל לא מעט פרטים - וזה כשל אבטחתי נוראי ברמה הלאומית, גם ברמת המידע שנחשף וגם בקלות בה ניתן היה להשיג אותו.
      • כל כך קל שזה מכעיס. רק צריך ללבוש קפוצ’ון . . .
    • עכשיו זו פשוט פצצת זמן שממתינה.
    • (דותן) רגע - אז אפשר להצביע דרך הדבר הזה? להכניס רשומה . . .גאוני.
    • אפשר לחשוב רגע על מגוון המחדלים שכנראה היו פה - 
      • כל מאגר הבוחרים נמצא במקום שמוגן בסך הכל ע”י סיסמא (ב-Clear text כמובן)
      • ה-URL של הסיסמאות פשוט זמין בתוך אחד מעמודי ה-Web הלא מוגנים
      • בגדול - ביטוי המפתח הוא “מישהו תכנן”. לא נראה ככה . . .
      • המון דברים שגם אם עושים מהר וחפיף - מי שומר סיסמאות ב-Plain text בדף Web? מסתבר שיש.
    • תעודת עניות להמון גורמים בשרשרת.
    • חשבתם שזה נגמר? אחרי החשיפה: פרטי 6.4 מ' ישראלים ממשיכים לדלוף
    • וזה פשוט לא מפסיק . . .
  • לנשום עמוק . . .
  • בשבוע שעבר התקיים כנס GopherconIL
    • הכנס התקיים כבר, אבל תוכלו לצפות בהרצאות המוקלטות, לכשיפורסמו.
    • גם רן וגם אלון דיברו בכנס
    • רן דיבר על go-grpc-channelz (דיברנו על זה בבאמפרס 61) - מספק visibility לתוך gRPC, שהיא מערכת RPC רובסטית וטובה, אבל גם מורכבת - והפרויקט מספק עוד Visibility, בעיקר לתוך ה-Clients (לאן מחובר, איך עובד ה-Load balancing, וכו’), והכל בממשק וובי די פשוט.
      • מעיין הרצאת Ignite של 10 דקות
    • אלון דיבר על Go is Getting Rusty - לאורך השנים דיברנו הרבה כאן על Go ו-Rust
      • האם צריך בכלל להשוות בינהן, קצת על מה זה Rust ולמה זה מעניין . . בקרוב הוידאו.
    • אחת הדמויות הבולטות בעולם ה-Go נכח גם - Dave Cheney
      • ביקר בישראל, היה ה-Keynote speaker וגם העביר סדנא שנזכיר עוד מעט.
  • בעניין דומה ל Go ו-Rust - פוסט של חברת Discord שמדבר על למה הם עברו מ-Go ל-Rust באחד ה-Services שלהם.
    • כתוב יפה, מסביר כל מיני מגבלות (ה-Garbage collection של Go…)
    • הנושא לא מפתיע - כל מי שעובד עם שפה שהיא Garbage-collected חייב להיות מודע למגבלות של ה-Garbage collector. נכון שיש כאלו כמו של JVM שמאפשרות קצת Tuning ואולי במקרה של  Discord היה אפשר להשמש ב-Java או ב-Kotlin כדי לספק את הצרכים שלהם עם ה - Garbage collector, מה שב-Go כמעט שאי אפשר לעשות.
    • בסופו של דבר, אם חשוב לכם Raw Performance ושלא יהיו עיכובים אפילו לא באחוזון ה-99 ועם Latency מאוד נמוך (פחות מ-1mS) - יכול להיות ששפה שהיא Garbage-collected לא תתאים לכם.
    • צריך להכיר את המגבלות של הכלים - שפות שהן Garbage-collected בדרך כלל יותר קלות לפיתוח אבל יש להן מגבלות, וכאן הן מוצגות מאוד יפה ונראה שהמעבר ל-Rust מוצדק.
    • (אלון) אני חושב שחלק מהעניין נובע מההשוואה של Go ל-++C, וזה לא כל כך נכון - אולי לפעמים מגיעים ל-Performance שמתקרב ל-++C, אבל זה לא שם בהרבה מקרים ולא באמת תחליף בהרבה מקומות.
    • (רן) תלוי בהקשר - במקומות שבהם אתה כותב ++C אבל לא מגרד את יכולות הניהול זכרון אז זה לא כל כך משנה; במקרה הזה היה להם הרבה מאוד דאטה - Caches גדולים ואינטנסיביים אבל עם מעט מאוד מקרי Revocation - ואז ה - Garbage collector עדיין נאלץ לעבור על כל האובייקטים וזה לקח הרבה זמן.

אלון - 
  • בהמשך ל Dave Cheney ו - GopherconIL - הוא העביר גם Workshop (יותר הרצאה-מאוד-ארוכה)
    • כתב על זה- Practical Go: Real world advice for writing maintainable Go programs
    • חלק מספר שהוא כותב - ואלו משהו כמו עשרת הפרקים הראשונים.
    • מגוון נושאים - הצהרה על משתנים ושמות משתנים, מתי להשתמש במה, הערות, Style . . .
    • מסביר איך עובד nil, שזה משהו קצת הזוי ב-Go (מסתבר שלא כל ה nil-ים זהים…)
    • ועוד רשימה ארוכה . . . מאוד ארוך אבל מעיין - נכנס לאיך הוא רואה את הדברים וזו נקודת פתיחה מעניינת לכל מי שכותב ב-Go.
    • (רן) גם השתתפתי בסדנא וקראתי (באמת ארוך) - כתוב יפה מאוד ומסביר דברים יפה ולא חוסך בדוגמאות.
      • מה שכן - לא בהכרח הייתי ממליץ למי שרק עכשיו לומד את השפה אלא למי שכותב כבר כמה חודשים ואז הדברים יהיו יותר הגיוניים.
      • הוא כותב על דברים שהם Battle-tested, ומי שרק לומד את השפה לא בהכרח צריך להבין את כל מקרי הקצה של טיפול ב-Channels למשל, אבל בהחלט קריאה מומלצת.
    • יש כאן ענייני שמות משתנים, החלק של ה-nil ועוד כמה דברים שיכולים כן להיות רלוונטיים, ואולי אחר כך רק מי שכותב ממש ב-Go יכול להמשיך.
  • שפת תכנות חדשה שמיקרוסופט הוציאו בשם verona
    • מוגדרת כ “Research programming language for concurrent ownership”
    • לא ברור מה המוטיבציה לשפת Research חדשה, אבל לקחו הרבה עקרונות מ-Rust וניסו לבנות שפת Research.
    • מדובר ב-Research במובן של שפות או בהקשר של Data Science? לא לגמרי ברור
    • (דותן) נראה כמו מחקר על שפות תכנות - עוד סוג של Meta (שפת תכנות שחוקרת שפות תכנות, ד”ש ל Inception)
    • (רן) חושב ש-Scala הייתה קצת כזו בתחילת הדרך, ומחבר השפה (Martin Odersky) אמר שיש בה כל מיני דברים שהוא תמיד רצה לנסות בשפות ועכשיו יש לו מגרש משחקים לנסות . . . אולי זה מסביר את זה.
    • בכל מקרה, לא ברור אם יצא מזה משהו, אבל יש כאן הרבה עקרונות מ-Rust (וגם מ-Pony, שאנחנו פחות מכירים - מפתחים שהיו פעם חלק מחברה ואז המשיכו לבד, משהו כזה)
    • המימוש של verona עצמה הוא ב++C.
  • שירות של AWS בשם Amazon Braket - והפעם: Explore and experiment with quantum computing
    • מה אפשר לעשות היום, כשחישוב קוונטי זה עדיין לא משהו עם הרבה יישומים בימים אלו?
    • לא לגמרי ברור, אבל אולי מישהו מהתחום יבין
    • (רן) אני יכול לנחש שאולי להריץ איזשהו סימולטור ל - Quantum Computing
    • (דותן) או שאחרי ההכרזה של Google על Quantum supremacy מישהו ב-AWS רצה מהר להריץ על משהו עם “Quantum”.
    • (רן) אפשר לראות תועלת בדבר כזה, גם אם אין לך גישה למחשב קוונטי אמיתי - אפשר ללמוד ע”י סימולטור את השפות והעקרונות. זה לא יפרוץ RSA בשעתיים, אבל אפשר ללמוד עקרונות ברמה טובה.
    • בקיצור - אם אתה באמת צריך, בסוף זה ירוץ ב - GCP. . . 
  • ואם כבר GCP - נראה שהייתה שם התלבטות האם לנטוש או לא, והחליטו כן עם זה (זאת אומרת לא לנטוש), ובכל הכח - ולהיות a top-two cloud player by 2023
    • זה לא ממש עתיד רחוק עבור מטרה כזו, וזה אומר שהם כנראה הולכים לשים הרבה משאבים על זה. יש להם - אבל גם לאחרים יש.
    • נראה מה יהיה עם העננים - ומעניין איך זה בכלל יצא החוצה (נראה כמו דיון פנימי די סודי של Google)
  • שירות חדש - Pulumi
    • הכותרת היא Modern Infrastructure as Code - מתחרה ל Terraform - פתוח, חינמי וכו’.
    • בשונה מ Infrastructure-as-a-YAML, שכבר אמרנו מה אנחנו חושבים עליו.
    • נראה מעניין, כולל גם השוואה בינם לבין Terraform
    • (דותן) זה דווקא נראה כמו פרויקט שקצת מעצבן אותי - עושה מעיין Singularity ואומרים שהם יכולים לעשות משהו מעבר ל “Declarative” של Terraform, עם עטיפה מוצרית והכל - אבל אם כבר מדברים על חופש, למה אני לא יכול פשוט לכתוב את כל זה בעצמי? כל העניין ב - Declarative הוא שאני רוצה שתיהיה מסגרת שגם תגביל אותי.
    • (אלון) אני חושב שחלק מהעניין הוא שאתה גם Cross-Cloud עם זה . . .
    • (רן) נראה שההבדל הוא בעיקר בממשק המשתמש
    • (דותן) זה שאני יכול להשתמש יותר בשפת תכנות נותן לי יותר כוח בסופו של דבר, אבל אם כל הרעיון שבגללו אני הולך ל Terraform הוא עבור המסגרת והסדר, אז אני לא רוצה את עולם שפות התכנות כי אני לא רוצה סיכון . . .
    • (רן) מזכיר קצת את Cheff מול Puppet של לפני כמה שנים - Cheff בא עם Ruby שאפשרה לתכנת את ה-Infrastructure ו-Puppet נתנה DSL עם מעט מאוד Constructs. 
    • (דותן) … ושתיהן התכנסו לכיוון של תכנות, כשאף אחד לא באמת עצר אותך (מלולאות אינסופיות וכו’) - זה טוב ל-80%, אבל מי שצריך את ה-20% צריך לעבור פרדיגמה לחלוטין.
    • (אלון) אולי זה מקרב את המפתחים ל-Infrastructure, לטוב ולרע - אחרת נוצר ניתוק עם מערכות אחרות, ברגע שזה קוד אז יש סט אחר של כלים ו-Unit tests וכו’.
    • (דותן) כל עוד יש מסגרת זה נהדר, אבל אם אין מסגרת? “קח את המסגרת ותעשה מה שאתה רוצה”, יש גישה ל-S3 וכו’ ותעשה מה שאתה רוצה. איפה זה עוזר לי, בהנחה שאני לא מישהו שמכיר את כל ה-API בע”פ ויש מצב שאני אעשה טעויות?
    • (אלון) אני חושב שזה יותר מזה - יש כאן גם Environment ו-Roll-backs ובעצם כל מה ש - Terraform נותן. אם פשוט תתחיל לעבוד עם ה-APIs לא תגיע לאותו מצב.
    • מן הסתם זה לא ברמת בשלות של Terraform שכבר הפך למפלצת, אבל יכול להיות מעניין, לפחות בינתיים.
  • יש repository בשם earthengine-py-notebooks - אוסף של מעל 300 Jupyter Python notebook examples for using Google Earth Engine with interactive mapping
    • למי שמעניין ממשקים עם מפות, Jupyter Python notebook וכו’ - יש כאן המון דברים יפים.
    • זה משתמש ב-API של Google Earth, אפשר לראות וידאו קצר - אז אם רוצים לראות כמה דברים בשביל רעיונות, יש כאן מלא.
  • ועוד לדיון ה Go/no-Go - עוד Plug-in ל-VS Code בשם Go Autotest
    • מאפשר להריץ טסטים ואז הכל מסתדר, נחמד ומומלץ למי שעובד עם VS Code
  • עוד Go שמבטיח “Json for Humans” - אז HuJson
    • מי שרוצה להשתמש ב-Json ולכתוב comments - מוזמן להשתמש בזה.
    • (רן) מבאס שאין Comments ב-Json . . . הרי זה התחיל מ-JavaScript ושם כן אפשר להוסיף הערות, אז למה כאן לא?
    • (דותן) זה בעצם Jason5 - זה הסטנדרטי.
    • (רן) עדיין - ב-JavaScript ה-Json הוא בסך הכל אובייקט ושם אפשר להוסיף הערות, אז מתי זה ירד?
    • (דותן) זה רק היה מביא לפיתוח סטנדרט של Json-for-Machines בלי הערות…
    • (אלון) זה דומה ל-JavaScript אבל לא לגמרי, אולי רק לקחו את השם.
      • וזה בא אחרי XML שבוא גם היו הערות
    • (דותן) Json הוא פורמט Serialization יחסית מהר, אז אולי ככל שהוא יותר פשוט ככה הוא יותר יעיל וזה חלק מזה.
      • (אלון) למה לבאס? בכל מקרה, צריך Comments. אנחנו בעד.
      • מה 7? מה כמה. זו הערה.
      • וגם אפשר להוסיף שם את הסיסמאות Admin, אחרת איך יהיה אלקטור?
  • ובהמשך ל”כולנו קומונה ושיתופי וחינם וטוב לנו” - DL HUB הוא A simple way to find, share, publish, and run machine learning models and discover training data for science
    • יש כאן Hub עבור מי שרוצה להריץ Machine Learning ,עם המון דוגמאות ומקום שאפשר להעלות ולהריץ כל מיני שטויות (או שלא).
    • לא חקרתי, נשמע חביב.
  • ועוד אחד - שאלות ותשובות ל Cloud Run
    • די דומה ל-FarGate של AWS אבל לדעתי הקונספט יותר מגניב - קצת כמו Lambda, רק של Docker, ואז אתה לא צריך להתעסק עם Run-time וכו’, רק לקחת Docker.
    • יש יתרונות על Lambda כמו אם חסר לך משהו בספריות וכו’.
    • עדיין בטא, אבל אני חושב שבעתיד זה יהיה מגניב.
    • וכל זה- כי מישהו יצר מסמך FAQ, לא רשמי של Google, שמסביר את ההבדל אל מול AppEngine ו-FarGate וכו’.
    • אפשר להוסיף ולערוך ולקרוא ולהסכים.
  • בלוג-פוסט בשם A Brief History of Containers: From the 1970s Till Now
    • סקירה של ההיסטוריה של Containers, החל מUnix v7 והלאה, Dockers ואז K8s ב-2017 . . .
    • למי שמתעניין בהיסטוריה וב-Containers (באמת יש חיתוך בין הקבוצות?) 
    • (רן) זה חלק מהבלוג של Aqua שהיא חברה ישראלית, ונראה קצת כמו PR שנועד להביא גולשים.
    • (דותן) רק לדייק - לא היו באמת Containers ב-1970 . . . זה התחיל סביב 2000. Docker התחיל כשילוב של כלים, שבעצמם באו על בסיס רעיונות קודמים.
    • (אלון) לכולם יש אינטרס, ועדיין - משעשע.

דותן - 
  • זוכרים את האייטם על Pulumi? אז זה כן יכול להסביר את הגישה של החברה: אליל נוער שלי בשם Joe Duffy
    • לא להקת רוק. . . האיש שמבין Concurrent Programming.
    • יש כאן (באייטם של Pulumi) עוד כמה חבר’ה ממיקרוסופט, אז אולי יש כאן גם עניין עם תמיכה ב-Azure
    • בכל מקרה - נאחל להם בהצלחה, אבל את הדעה שלי כבר שיתפתי ... 
  • אתר (שכבר כיסינו בעבר?) בשם Illustrated.dev
    • אתר מדהים עם ציורים של כלים, ספריות ועקרונות מעולם הפיתוח.
    • ספציפית - מאמר שעוסק ב-immer, שזה Immutable Data ל-DataScript.
    • אחד הפוסטים היותר חשובים שקראתי, גם כי Immutable Data זה משהו שקשה להבנה
      • וגם יש לו שם בעייתי, אולי יותר נכון לקרוא לזה Persistent Data Structures? מבנים שעושים בהם שינוי והם יודעים לשנות את עצמם בצורה יעילה.
    • אם יש עץ כלשהו עם הרבה Nodes ואז עשיתי שינוי באחד התת-עצים, המבנה אמור לבצע את השינוי המינימלי בכל השרשרת של העץ למטה, כך שאם נשווה את העץ החדש לישן, ברמת ה-Root, זה יהיה אי-שיוויון, מבלי להעתיק את כל העץ.
    • אבל כאן יש ספרייה שכולנו מכירים, ומישהי שלקחה את הספרייה וציירה את כל מה שבפנים עם כל העקרונות, וזה מאוד עוזר להבין את האינטואיציה  מאחורי הספריות.
    • מנסיון - הרבה מאלו שעובדים עם Immutable Data structures לא כך מבינים מה עומד מאחורי וזה יוצר הרבה טעויות.
    • (רן) אחת הדוגמאות הקלות יחסית להבנה של העקרון זה Copy-on-Write - אתה מעתיק קובץ, וכל עוד לא שינית אותו אז עלות הפעולה מאוד נמוכה. רק כשאתה באמת רוצה לשנות מתבצעת ההעתקה “האמיתית” (סוג של “Lazy copy”).
      • במבנה הנתונים יש הרבה יותר תחכום, אבל זו היכרות עדינה עם הנושא
    • אחלה הסבר - ועכשיו מי שרוצה וממש מתעניין צריך לחשוב על איך עושים את זה באופן יעיל, ומה עושים כשיש קבצים שתלויים בקבצים וכו’.
    • מאמר מאוד חשוב - שווה לקרוא גם אם אתם לא מתעסקים עם Persistent Data Structures בשביל להבין את החשיבה.
      • למי שמעניין - Google it…
    • באילו שפות משתמשים בזה? Clojure זו אחת מאבני הבניין, שילוב של פרקטיות ו-Mindset;
      • יש את hasql שהיא שפה פונקציונאלית ו- Immutable אז אין כל כך ברירה
      • ולשפות יותר פרקטיות - JavaScript . . . למה בעצם? כל הסיפור של Redux בעולם ה - Frontend.
      • הרי Redux ו - Flux וכל הארכיטקטורה הזו נולדו מתוך Elm, שזה Framework שנולד מתוך עולם פונקציונאלי.
      • בגלל שזה מגיע מהמקום הזה, ב-Redux יש עקרון של Immutability - בכל שינוי שאתה עושה אסור שיהיו Side-effects.
      • מהמקום הזה, תרצה לקחת איזשהו Data Structure שמאפשר לך להיות Immutable או להימנע מ-Side effects כעיקרון - וזה עוזר אם יש לך Immutable Data structure להשתמש בו.
    • וככה חזרנו ל - immer . . . זו אחת מהספריות היותר פופלאריות של JavaScript, בהקשר (בסוף) של שימוש ב-Redux ב - Frontend.
    • וזו (מועמד לשיא גינס בסגירת סוגריים) דוגמא ב-Mass-adoption לשפה שצריכה Immutable Data structure.
  • ספרייה מגניבה בשם grex
    • וזה עוד לפני פרויקט Greps שעושה Grep-(ס)ים . . .
    • מדובר בכלי/ספריה ב - Rust שמאפשר לקחת ביטויים ולחלץ מהם Regular expressions.
    • ראינו כאלה כבר בהיסטוריה (משהו כמו 10 שנים אחורה) עם כלי שנקרא GROK (יש עוד הרבה בהקשר של LogStash), שאפשר לתת לו כמה שורות של לוג ואז הוא “מצליח להבין על מה הלוג מדבר” - אם זה Apache וכו’.
    • אז כאן מגיע grex עם אותו עיקרון, רק שהוא מנסה להוציא Regular expressions בהתבסס על כמה דוגמאות.
    • פינת העובדה המוזרה - מאיפה מגיעה המילה GROK? המשמעות היא להבין”, אבל מדובר בסלנג שמגיע מסרט מדע בדיוני מפורסם שבו הומצאה המילה ומשם זה נכנס
  • כלי בשם git-sizer שאפשר להריץ על ה-Repositories שלכם ב-Git ולראות אילו מהם “לא בריאים”
    • ההגדרה - “Git repositories should be under 1 GB” - ומה שגדול יותר כנראה יתחיל לג’עג’ע.
    • הכלי עושה ניתוח יפה של ה  -Git Repo וגם מוצא את האובייקטים היותר גדולים יחסית
    • יש גם הסברים על איך לתקן
    • מי שה-Repo שלו כבר איטי - אז כנראה שיש סיבה, וזה אחלה כלי כדי לנתח.
    • נחמד שזה בא מ-GitHub, כתוב ב-Go (דותן בכלל הגיע לזה ממקום של להסתכל איך זה כתוב).
  • ספרייה בשם jsonrpc
    • מדובר בפרוטוקול לא חדש וגם לא כל כך פופלארי היום - כשכולם עושים gRPC (לא, זה לא אותו הדבר).
    • זה פרוטוקול transport-agnostic, שהמטרה שלו הייתה לנסות לנסח RPC בין שני רכיבי תוכנה כך שיהיה מבוסס על json.
      • בהנחה ש-json הוא פורמט Serialization די פופולארי שכולם מכירים.
    • אנחנו רוצים לקרוא למתודה, להעביר פרמטרים ולקרוא return value.
    • כל זה הוגדר כ json Object - רושמים את השם של המתודה ואת הפרמטרים (Array, dictionary וכו’) - הכל מוגדר ב-Spec יפה ומסודר.
    • אם רוצים פשטות, הפרוטוקול נותן Transports די מעניינים
      • למשל - HTTP Server, שזה משהו שאנחנו רגילים לצפות לו ויש גם ב-gRPC- אבל יש גם TCP Server שזה יותר “Old School” (ממש Line Protocol - “אני שולח שורה, אתה שולח שורה” - מגניב יעיל, פשוט).
      • יש גם Web socket server, אותו סיפור - אם מעבירים שורה קדימה ואחורה, אז אפשר לעשות את זה גם על Web Sockets.
      • יש ICP Server
      • וגם  -STDIO Server - להרים Process, להזרים אליו שורה אחת ואז לקבל חזרה שורה אחת. אושר.
    • הספרייה הזו ספציפית נכתבה ע”י Parity (קשור ל Blockchain Parity), סופר-איכותית, מאפשרת לזוז בין הפרוטוקולים בשורה אחת בלבד.
    • וגם כתוב ב-Rust אז מאוד יעיל.
    • עולם שלם של יתרונות, לא מצאתי עדיין חסרונות, אחלה למי שבונה Client-Server Architecture - אני הייתי צריך את הכל באותו ה-Host ורציתי פשוט, אז זה מגניב.
  • (רן) עדיין עם GROK מהאייטם הקודם  . . . חוזר אחרי עדכון ויקיפדיה - זו כן מילה באנגלית, אבל הפכה פופלארית ומשמעותית במדמ”ח בעקבות Stranger in a Strange Land של היינליין.
    • (דותן) מתי מתקצרים את הספר? אולי יש שם גם קונפיגורציה של LogStash. . .
    • (אלון) ואז גם אפשר לשנות את שם הפודקאסט ל”עושים באמפרס” . . . רן לוי קורא את זה? אם גבר, אז הפרק על היינליין מעולה.
  • ובחזרה לאייטם - לא להתבייש להשתמש jsonrpc, לא חייבים gRPC, יש עוד דברים.
  • ספרייה בשם dialoguer
    • גם ב-Rust
    • יש ספרייה למי שמכיר בשם prompt.js, ועוד ספריות דומות, שמאפשרות לקחת Input מהמשתמשים (כנראה Developers) - השלמת סיסמאות, check-boxes וכו’.
    • באופן מפתיע אין כל כך Read-me . . . מי שבנה את זה מכונה mitsuhiko, מיודענו מעולם ה-Python וה-Rust ושאר דברים טובים, אחד האנשים המרכזיים בעולם הפיתוח וה-Open source.
    • (אלון) היה נחמד אם היו תמונות לראות מה הם עושים . . .
    • (דותן) אולי הוא לא ממש רוצה שזה יהיה פומבי, ואנחנו בבאמפרס מביאים את זה בכל זאת לכותרות.
    • זו הספרייה היחידה ב-Rust - ככה זה, ולפעמים זו הספרייה הכי טובה שאפשר למצוא.
      • שינוי מרענן, אין את פרדוקס האפשרויות ועשר ספריות שכל אחת טובה בצורה מסויימת שונה וחסרה במשהו אחר.
  • בהקשר דומה - ספרייה נוספת בשם fiber
    • סוג של Express (של Node.js) על Go - כשהתחלתי (דותן) עם Go לפני 10 שנים, זה אחד הדברים הראשונים רציתי לעשות.
      • רק שזה לא משתלב ב “Go המסורתי”.
    • מסתבר שיש דברים שצריך לתת להם את הזמן שלהם - ופה בא מישהו ועשה משהו ש-Literally נראה כמו Express מבחינת ה - Developer Experience, שזה מגניב.
    • טיפל בעוד כמה דברים מבחינת Performance (לא הכל) - ועכשיו אנחנו בעולם שיש בו Express ב-Go.
    • לא ממש העולם ה - “idiom-טי” של Go אלא נראה ונקרא כמו Express.
    • במשך השנים למדתי ללכת עם Compatibility ולהסתמך על ה - Standard Library של Go (ועל ה - Approach ועל ה - Mindset), אבל פה יש ספרייה שהיא פופולארית “בין-לילה” שזונחת את הסיפור הזה . . . והכל בסדר.
    • (רן) אני משתמש בספרייה נוספת שעושה את אותו “תעלול” שבנויה מעל fasthttp, יותר low-level implementation או מעיין מימוש מחדש של net/http מעל Go, שהוא הרבה יותר מהיר.
      • זה מוסיף את ה-Routing מעל.
    • (דותן) גם הספרייה הזו נראית באותה גישה, ואולי זה סוג של טרנד (שהיה שם כל הזמן, רק שהרבה זמן עדיין הלכנו על הסטנדרט של Go על מנת להימנע מכל מיני בעיות Comparability). אולי זה כבר לא משנה?
    • (רן) אני חושב שזה עדיין משנה - אחד האתגרים שלי עכשיו למשל הוא להוסיף Middlewares שונים, ובעולם של net/http יש את כל מה שאתה רוצה - Tracing לסטטיסטיקות, ל-Log-ins וכאלה - זה מאוד קל, רק תבחר ותוסיף. ב-Framework אחר זה פשוט לא תואם ואתה צריך לכתוב בעצמך.
      • חלק כתבתי וזה לא כל כך מסובך, אבל זו עדיין עוד Liability וקוד שצריך לכתוב ולתחזק, ויש גם “קצוות לא משוייפים” (ה-Context  לא תמיד מתאים).
    • (דותן) פעם גם אמרתי שאולי כדאי לקחת משהו עם Developer experience יותר טוב - בתקופה שלא היה Context ב-Go בכלל.
      • ואז זה נולד, ומצאתי את עצמי חסר יכולת להתחבר ל-concept הזה בכלל . . . עבדתי בלי זה הרבה זמן, ו”כל היקום כבר הלך לשם” ולא הייתה לי ממש ברירה כי אני מבין את היתרונות שבהצמדות ל-Standard Library של Go ולא ללכת ל”נתיב צדדי”.
    • (רן) רק מבאס שה - Performance של הספרייה הבסיסית של net/http הוא פשוט הרבה יותר גרוע . . .
      • נובע מבחירות Design שהם עשו לאורך הדרך
    • (דותן) עכשיו אנחנו מסתכלים על fiber, שב-Read me שלו יש “Express inspired web framework” ומעניין לראות איך זה יתפתח - 
      • אחרי ש- Express נולד לא הייתה לגיטימציה ליותר מ-Framework אחד, ואז נולד Kora ואז nest.js  ועוד.
      • ברגע שנפתחה הדלת, יכול להיות שבעוד כמה חודשים נראה אולי עולם חדש של “דמויי-Express”, פחות דומה למה שהיה עד עכשיו אבל עם Developer-experience יותר דומה ל-Express.
      • אני רוצה לנסות ולראות איך זה מרגיש.
  • עוד ספרייה ב-Go בשם fyne, שמתוארת כ”Cross platform GUI in Go based on Material Design
    • לא רואה כאן הרבה Material Design אבל כן הרבה UI שמרנדר (render) מעיין Widgets אחידים בין פלטפורמות.
    • מבוסס על OpenGL
    • למי שרוצה ליצור UI שהוא Cross-Platform ורוצה Binary קטן ולא רוצה לארוז הכל ב-electron עם 50Mb ב-Zip ועוד 150Mb פרוש . . .אפשר לשקול את האופציה במקרה שרוב הלוגיקה בצד של Go / בצד של ה-Binary ולא בצד של ה-UI.
    • נראה כמו ספרייה שכבר עברה לא מעט Mileage, נחמד.
  • וברוח התקופה - קצת Coronavirus כי אפשר בלי - יש מלא אנשים שאוספים Data-sets . . .
    • לא ברור אם זה יהיה רלוונטי עד שהפרק יהיה באוויר (עושה רושם שכן, בעיקר בראשל”צ…)
    • במידה וכן ואתם מאזינים מהבונקר האטומי שלכם - הנה repo בשם COVID-19 (שזה מסתבר השם החדש של הוירוס) ששייך למרכז ל-Systems Science & Engineering של אוניברסיטת Johns Hopkins
    • למי שרוצה לכלך את הידיים - אבל באופן סטרילי . . .
  • וכאן יש את free-for-dev - יש כמה כאלה אבל זה מאוד פופלארי
    • חשבונות חינמיים, Servers, כלים, Storage . . .
    • כוכבית - אם אתם רואים משהו שאתם אוהבים, זכרו שיש מאחורי זה מפתחים רעבים. שלמו . . .
    • שום דבר לא גנוב, כן? הכל Trails וכאלה.
  • דיברו על MDX בעבר (למשל באמפרס 50), וכאן יש את mdx-deck.
    • אז MDX זה Markdown משולב עם React, מגיע ממפתח בשם Brent Jackson, שהפך למעיין “אושיית UI / Frontend” שגם מפיק כלים מאוד מתקדמים.
    • עובד ב-@gatsbyjs, שזה כוח אש יפה
    • בכל מקרה - הוא בנה ספרייה בשם mdx-deck
    • אז MDX בכלל זה Markdown שמאפשר לקחת רכיבים של React ולשלב לתוך Markdown
    • בהנחה שההרצאות בהקשר הזה מוכוונות Frontend ורוצים להראות דוגמא של רכיב ב-React, פשוט אפשר לעשות Import ו-Render לתוך הMarkdown, ואז אפשר גם להוסיף טקסט, תמונות ומה שרוצים.
    • דרך סופר-מהירה לשלב קוד ו-deck “מסורתי”
    • וזה גם יכול להיות אינראקטיבי - אם יש כפתור אז אפשר ללחוץ.
    • בכלל  - MDX זה אחלה פורמט לייצור עזרים ויזואליים שהם לא אתרים או משהו כזה.
  • בלוג-פוסט של דותן על המורשת של אותו Brent Jackson תחת הכותרת 4 New Theme Based React UI Toolkits and Why It’s Going To Change How You Think
    • האיש נמצא בחזית של קונספטים מתקדמים ב-Frontend וייצר כמה ספריות מאוד משמעותיות בתחום
      • אחת מהן היא Rebass - נראת קטנה ושטותית במבט ראשון אבל במבט שני מאוד משמעותית - עם עקרונות מאוד מתקדמים של UI
    • הוא גם פיתח את Theme UI, שזו ספרייה ש gatsbyjs משתמשת בה (עם אותם עקרונות)
    • ואחרי זה - styled-system, שהיא עוד ספרייה שאומרת שאם בונים Design System ב-Frontend, אז אחד העקרונות החשובים זה Theme והיכולת להחליף את ה-styles לפי דרישה.
      • בכלל - הארכיטקטורה שם זה משהו שהוא חשב עליו המון, והיה צריך לייצר כמה וכמה ספריות - 
      • כל ספרייה כזו זה משהו כמו שנה בפיתוח ואלפי Stars והמון Communities
      • כל ספרייה כזו גררה אחריה המון פידבק ממפתחים, כך שכל אבולוציה היא מואד משמעותית והוא הגיע לספרייה או חבילה מאוד טובה - Theme UI - שזה הסטנדרט וה-Go-To שלי - לא רזה מדי ולא שמן מדי - ומי שלוקח את זה יכול ללמוד המון על איך לעשות UI כמו שצריך מהספרייה עצמה.

ולחלק המשעשע (או לפחות מנסים) - 
  • ניסיון לענות על אחת השאלות הפופולאריות ב-Stack Overflow, שהיא כמובן - איך יוצאים מ-VI?!
    • בפעם הבאה - מה הטעם בכבישים ללא מוצא?
    • מדובר ב-Repo בשם how-to-exit-vim, ועושה את זה בדרכים מאוד יצירתיות, מעבר לEsc+Q או Esc+X
    • למשל - קריאה ל-Shell ואז grep ו-kill פשוט כדי להרוג את VI, או find לתוך קבצים שמתארים את ה-processes השונים . . .
    • אפשר עם Perl ו - Python ו-Ruby ועוד המון דרכים יצירתיות.
    • (דותן) אהבתי את האופציה ל-Reboot, זה מה שאני עושה.
    • (רן) יש גם את גישת ה-Passive-aggressive - להפעיל Fork-bomb ב-Bash ואז (בין שאר הדברים הרעים אז גם) VI קורס.
  • ועוד אחד - אפליקציית Look Busy . . .
    • ברגע שמתקינים על הטלפון היא מוסיפה פגישות מזוייפות - שנראות אמיתיות:
    • “ מחוייט ועסקי”, אפשר להגדיר במה אתם עוסקים והפגישות יהיו בהקשר הנכון
    • אפשר להגדיר שעות לפגישות המזוייפות - ואתם נראים מאוד עסוקים כי יש לכם מלא פגישות.
    • המטרה בגדול היא שיעזבו אותך בשקט ושתוכל לעבוד.
    • זיכרו איפה שמעתם על זה בפעם הראשונה! אנחנו עסוקים עכשיו.



הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול