עונה 3 פרק 2 - פרק פשוט על נושא מורכב - דולב פומרנץ דירקטור בינה מלאכותית בגונג

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

the hidden cost of complexity

jumping down complexitys rabbit hole

Episode Transcript

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

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

(00:48):
אני לא יודע אם נגמרה המלחמה אבל יותר רגוע אחרי קורונה אנחנו חוזרים למשרד להקליט מהמשרד.
החדש פעם ראשונה מהמשרד החדש זה אירוע חד פעמי אפילו הבאנו את שלום.
שלום.
המפיק שלנו שבא ושותה קפה ומתרגש מהקורסה.
טוב וגם אתה חזרת אחרי איזה אלף טיולים ביפן.

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

(01:32):
זהו.
וטוב מה, מה, מה גונג עושים?
וואו אז גונג היא פלטפורמה שבעצם עוזרת למכירות.
בעצם אנחנו,
תחשוב על חברות כמו החברה שלכם וחברות אחרות שרצות למכור לחברות אחרות.
אז במה הם נעזרות?
אז גונג היא בעצם פלטפורמה שמאפשרת לך לעשות end-to-end את תהליך המכירה,
מלהשיג לידים,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(08:11):
אז אני דווקא כן רוצה דוגמה כי אני לא בטוח שכולם מבינים אותנו אז אני אקח את סף אתה מכיר לו לא מעט.
אז כשמסתכלים על ספר ורוצים לעשות לו קונפיגורציה יש לך כמה?
1500 פרמטרים?
קצת יותר.
אוקיי אז זה מורכבות אוקיי כשאנחנו מדברים על מורכבות זה למשל דוגמה למורכבות למה כי עכשיו כל קומבינציה בין בין קונפיגורציה כזאתי בעצם צריכה עכשיו להתהמך מישהו צריך לעשות עליה QA.

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

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

(09:21):
שהיה אמרתי אבל עשיתי את זה,
מה שצריך לעשות, אתה לא יודע פיצ'ר זה לא עובד.
יש לך כאילו פלייג כזה ו...
לא, זה פיצ'ר שלא עובד.
הוא קיים, הוא מתועד, הוא זהו פה והוא לא עושה כלום.
באמת אמיתי אמיתי.
אבל זה תוצרים של מערכת שהיא מורכבת מאוד ויש לה כל כך הרבה אפשרויות
שכבר מגיעים למצבים כאלה.

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

(10:04):
mental model, איזשהו מודל מחשבתי שאמור לעזור לנו להבין את המשמעות של מה שאנחנו עושים.
בעיניי הדרך להסתכל זה תחשוב על התלויות שיש לך בקוד,
בין כל מיני חלקים שונים של הקוד,
זה יכול להיות סרוויס שמדבר עם סרוויס אחר,
ה-CICD שיש להם,
כל מיני דברים שקשורים בקוד שלי אפילו אני רוצה להוסיף פרמטר לפונקציה.

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

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

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

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

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

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

(12:40):
איך מפשטים?
זאת אומרת בסוף באה עם בעיה והפתרון הוא תוסיף if.
אם לא תוסיף את הif אתה צריך לפתור את הבעיה בצורה אחרת.
הבעיה לא תיפטר מזה שאנחנו נחשוב עליה ובדרך בל אז אם זה לא if פה זה פתרון אחר שם.
איך איך מפשטים בכלל איך מורידים את הסיבור?
הבעיה קיימת.
אם את הבעיה צריך לפתור.

(13:00):
מגניב אז קודם כל השאלה הראשונה שלך אז אתה אומר בוא נוסיף if ואז זה פשוט נכתוב את הטסטים.
אבל כשמשהו מתפוצץ מעריכי אין לך יכולת לכתוב את כל התרחישים שיש דה-פקטור כמות הטסטים שיש לי.
היא צריכה להסתכל עליה כאיזשהו תקציב יש זמן מסוים שאני אקצא לבדיקות אין כזה דבר 100% coverage לא היה לא יהיה.
100% coverage קורה אך ורק בפרודקשן לצורך העניין שרצים כל התרחישים השונים בסקייל גבוהה.

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

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

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

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

(14:55):
אבל זה לא מתאים לתוך האקוסיסטם הכללי ואז בעצם מוסיפים את הסיבוכיות רק אני רוצה,
אתה אנחנו אילן ואני עובדים ברדיט זה מאוד אופייני בעולם האופן סורס.
בעולם האופן סורס מאוד אופייני שפתאום כתבו מודול חדש כל תוכנה כתובה ב-C++ כתבו מודול חדש בראסט.
למה בראסט?

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

(15:40):
זה משהו תורם.
Take it or leave it.
זה חשוב גם אני בעד.
כאילו השינוי זה שאנחנו משתנים זה שאנחנו גם לומדים דברים חדשים לפעמים
מגיעות טכנולוגיות חדשות שהן יותר טובות זה אחלה לא צריך לעצור את זה התוכנה תמיד תשתנה.
מישהו פעם אמר לי קוד טוב זה קוד חי קוד שמשתנה זה לא קוד שהוא קפוא וסטטי ואם
מגיעה טכנולוגיה חדשה שעשה משהו יותר טוב זה אחלה אבל זה בדיוק כל העניין של לאזן את זה.

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

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

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

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

(17:26):
תלוי אבל סתם בשביל העניין אבל למשל בעולם הג'אווה להכניס ספק כמו סקאלה זה שינוי קטן אתה עדיין רץ על ה-JVM אתה עדיין זה זה שינוי קטן שאולי נותן value.
לעבור את להעביר את כל הסטייק למקום אחר כמובן שהוא לא תואם וזה זה שינוי מסוג אחר וזה.
גם במקומות אחרים זאת אומרת יש לפעמים יש טכנולוגיות שהם פחות disruptive חדשות והם הרבה פחות disruptive מטכנולוגיות אחרות.

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

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

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

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

(19:27):
את הארטסורסינג לקומפוננטה הזאת.
אגב, תורים, איך קוראים לשירות את זה באמזון?
SQSSN?
כן, simple q-service.
נכון.
כמו simple storage service.
נכון.
אתה רואה כמה באמזון זה ממש חרות על נגלם בהקשר הזה.
בסדר, טוב.
אגב, אגב, אגב, אני אגיד לך את הצד השני צריך רמה מסוימת של בגרות בשביל

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

(20:09):
ויכול להיות שעוד שנתיים אני צריך לעשות איזה מעבר כי
יפסיקו לתחזק את זה לטובת הדבר החם הבא,
אבל עדיין אני לא עושה את זה, יש את ה...
אין ה-H סינדרום, לא אינבנטד כאן, אנשים מאוד מאוד קשה להם.
להחליף קוד שהם כתבו בקוד שבא מבחוץ.

(20:30):
וזה עניין של בהרבה בגרות,
לבוא ולהגיד זה לא ה-core ביזנס שלנו אנחנו לא מתעסקים באותנטיקציה אז
אנחנו לא מפתחים אותנטיקציה נתרכז בקור ביזנס איפה אנחנו ב-value ללקוחות.
אגב, ועוד משהו כאלה, לא תמיד זה צריך לדעת לבחור את הכלים הנכונים שבאמת יורידו סיבוכיות כי אתה יכול לקחת משהו...
מי שיוסיף לך סיבוכיות.

(20:51):
כן, משהו פשוט ולהחליף אותו במשהו שיש לו 1500 פרמטרים,
אז אתה אוסף את הסיבוכיות של ממקום אחר לא בקוד ב...
טוב אז אמרנו שאנחנו ננסה גם לתת דוגמה דרך השאלה ה...
אלמוטית,
מונו-ריפו או וואן-ריפו?
ויכוח אינסופי שמתנהל, למה אני צריך...

(21:14):
-מונו-ריפו ווואן-ריפו זה אותו דבר.
מונו-ריפו.
סליחה, מונו-ריפו.
-סליחה, סליחה.
שבוע שעבר אנחנו דיברנו על זה לפני,
לדעתי,
איזה חודש-חודשיים כשעשינו את השיחה,
התכנה,
ושבוע שעבר היה לי עוד פעם את השיחה הזאת.
זה איזה פיצ'ר שאנחנו מפתחים איזשהו מוצר חדש,
הדיון סובב סביב האם אנחנו רוצים לפצל את הפונקציונליות הזה על כמה ריפוים,

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

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

(22:24):
כן, אז השאלה איך אני מארגן את הקוד שלי, אם אני מארגן את הקוד שלי בהמון ריפואים שונים,
ואז שאלה שנשאלת זה איפה נמצא הריפו המשותף, איפה הקוד המשותף?
כי יכול להיות שהריפואים אין להם תלויות אחד עם השני,
אבל בדרך כלל יש איזשהו תלות,
התלות מגיעה,
יכולה להגיע גם מלמעלה וגם מלמטה.
בדרך כלל אנשים חושבים על ה-Librares,
אז יש לי איזשהו common,
איזשהו Util שכולם יכולים לעשות לו אימפורט אליו,

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

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

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

(23:51):
על סדרי גודל יותר גולים מאשר רוב החברות האחרות.
נכון?
יש הרבה חברות שהולכות לכאן ולכאן.
אני אגיד שכשאני מסתכל על הסוגיה הזאת זה סוגיה של כוח.
איפה נמצא הכוח?
האם הכוח נמצא אצל צוות התשתית או האם אנחנו מבזרים אותו אצל הצוותים השונים?
נניח ויש לי צוות תשתית חזק שמסוגל להכיל את האחריות של מונו-ריפו,
אז תחשוב שהם יכולים כל הזמן לדחוף קוד בתוך משהו common,

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

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

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

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

(25:40):
אז אתה כמפתח של פרויקטים אומר,
שמע,
אני מסיר ממני הרבה מאחריות,
שזה לב העניין,
ומישהו דואג לי ועושה לי הרבה מהדברים האלה,
חייב שיהיה את המישהו מהצד השני אחרת ברור שזה ילך לכיוון של לא טוב לי זה לא עובד
ככה וצריך לקרות את זה נחזור למה שדיברנו בהתחלה אם אתה עושה מונו-ריפו אז
שינויים כמו להוסיף פרמטר לAPI נהפך להיות קריטי כי אתה יכול לשבור במיליון מקומות,

(26:05):
שאתה לא יודע בדיוק איפה הם את הפורטביליות ואתה לא יכול לצאת את זה
גרדיוול ולהגיד טוב רק כשאתם עוברים על גרסה הבאה,
אז יש פה באמת עניינים של ה-Gavarnense הוא להחלטה על שינויים צריך להיות מאוד מאוד מובנית כי נורא קל לשבור,
תלוי בשפות כשאתה עובד ותלוי בזה אבל נורא קל לשבור Compatibility ופתאום אנשים בקצה

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

(26:53):
צריך לבקש מאנשים שמתישהו יעשו את השדרוג הזה קדימה ויתקדמו.
לכתוב את זה ב-release notes,
הם צריכים לקרוא את ה-release notes שהם עושים שדרוג ולראות שקרה משהו ולהחליט אם לקבל או לא.
אם אני רוצה אפילו לעבור מעבר לקווים ולהיות ראש גדול כזה אז אני יכול לעבור ריפו ריפו מהריפואים שאני אמצא ולעשות להם את השינוי הזה ולדחוף אותם כזה קדימה,
כנראה לא כזה יזרום אבל אני יכול בתיאוריה לעשות את זה.

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

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

(27:57):
ואם הוא יראה שנשבר משהו אה וואו מתוך 100 הפרויקטים שברתי שניים אני
יכול עכשיו ללכת ולדבר עם השניים הספציפיים האלה ולנסות להבין מה.
ברור שאני אנסה לעשות שינויים שהם כמה שפחות breaking.
לא למחוק או לשנות פרמטר אלא להוסיף פרמטר ברור שאני יכול לחשוב על דברים כאלה אבל אז
הגיע כל העניין של איך אני מפשט נכון וגם זה חלק מהעניין אז אפשר להגדיר פרוטוקול מסוים כמו כזה שרק מוסיפים או אז מה שאתה אומר זה שאנשים צריכים לדבר אחד עם השני.

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

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

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

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

(29:55):
כמות השינויים וכמות הדברים שקורים בתחום היא משוגעת.
וזה מגדיל סיבוכיות כמעט ביידפינישן כי אתה כל הזמן רץ להבין מה קורה ואתה לא...
אתה אף פעם לא fully updated כי עד שאתה גומר את האפדייט של אתמול הגיע האפדייט של היום.
אני חושב שפה אפשר לראות סיבוכיות בכמה ממדים.

(30:15):
ממד אחד זה אם אתה מסתכל על הספריות עצמם,
הם משתנות,
הם מוסיפות פיצ'רים,
לא תמיד יש באקורד קומפטביליטי.
דבר שני, גם התוכן עצמו משתנה.
זאת אומרת,
זה לא רק שיש שינויים בתוך הספריות,
פתאום מתווסף לך עוד יכולת,
פתאום מתווסף לך אג'נטיק ופתאום מתווסף לך מה הם הוסיפו בopen-AI,
הם הוסיפו structure output,

(30:36):
פתאום הם הוסיפו את הדבר הזה,
זה יכול להיות שלא הייתה.
אז פתאום זה...
זאת אומרת,
השוק נע כל כך מהר שמתווספות סיבוכיות מעצם אי-ודאות שיש בשוק.
נכון אבל זה כן דחף לפטרן של buy vs build בצורה הרבה יותר חזקה.
אם מקודם היית צריך להגיד אוקיי, אני רוצה עכשיו לשחרר מודל,
אז אני צריך לאסוף דאטה ולהבין את הבעיה עד הסוף ולאמן איזשהו מודל,

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

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

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

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

(32:25):
אנחנו,
אף אחד מאיתנו לא יודע,
כל הזמן אנחנו צריכים...
אתר הרודפים אחרי המודלים,
אחרי היכולות,
אחרי זה,
עד שאתה מבין מה קרה,
יצא עוד מישהו עם עוד מודל,
עם...
כן?
וזה...
בשביל לפשט אתה צריך קצת...
שלווה.
שלוות נט.
אתה צריך לחשוב,
לראות את הבעיה,
לנתח אותה,
אין לנו זמן לעשות את זה,

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

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

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

(33:53):
אבל יכול להיות שאין את היכולת היום אבל היא כן תגיע מחר.
יש פה כל הזמן את המרוץ הזה כי מודלים לא נולדו שווים,
לפחות לא ביכולות שלהם ולא בכמה הם עולים.
נכון אז אנחנו עושים גם וגם,
לצערי, בחלק מהמקרים האלה כי אפשר לפשט עד כמה שאפשר,
אבל כמו שאמרת בהתחלה צריך לזהר מ-Over-Simplification,

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

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

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

(35:20):
דיברנו על SKS או S3 כדוגמה למשהו שיש לו API מאוד פשוט אבל בפנים הוא
יכול להיות מאוד מורכב מאוד מורכב אבל הוא עם פחות קשרים כלפי חוץ הקשרים
שלו מתבטאים רק על ידי API הרשות כביכול שהוא מייחצן לך החוצה.
אז איך אתה מחלק את המערכת שלך כחלק מזה?
איך אתה ב...
כשאתה מתכנן משהו,
אתה רואה שאתה לא הולך לבנות עכשיו פירמידות שאתה אומר אוקיי זה מה שבאמת צריך אם נזקק את

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

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

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

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

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

(37:32):
זה להוסיף קומפוננטה,
זה מגדיל סיבוכיות,
זה לא מוריד סיבוכיות,
זה,
יש פה גם, זה מדבר מאבקי כוחות, למי יש את הכוח?
לאמזון יש כוח שיש למעט מאוד,
ל-AWSB,
יש כוח שיש למעט מאוד גורמים אחרים, הם יכולים להחליט.
בסדר, טוב, היה לנו פרק פשוט ולא כל כך פשוט לדעתי,

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

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

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

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

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

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

(40:01):
להתראות, תודה רבה.