רברס עם פלטפורמה

פודקאסט מספר 366 של רברס עם פלטפורמה - אורי ורן מארחים בכרכור את שחר בר מחברת Clicktale לשיחה על פירוק מונולוטים, שינוי טכנולוגיות וטיפים של אלופים.הפרק בחסות Next Insurance, שהם גם (במקרה) ספונסרים של Reversim Summit 2019 (שזה לא במקרה - שריינו תאריכים ובואו בהמוניכם).שחר בן 40 מרמת גן, נשוי +2 - בתחום משנת 2000 ובארבע (וחצי) השנים האחרונות ב-Clicktale.בשלוש השנים הראשונות ניהל את קבוצת ה-Back-end ובשנה וחצי האחרונות הוא ה-CTO של החברה.חברת Clicktale נוסדה בשנת 2006 ע”י ד”ר טל שוורץ (ממייסדי מרכז היזמות של הטכניון והמרצה המיתולוגי של קורס הייזמות) ואריק יבילביץ’ (שהיה סטודנט בטכניון), על בסיס הרעיון שניתן “להקליט” את מה שמשתמשים עושים באתרים (את הקוד או את ה-Events ואת הבחירות) ולהשתמש בזהלמשל - “לנגן” וכביכול “לעמוד מאחורי הכתף” של המשתמש, ואז לנתח התנהגות של אלפי משתמשים כאלה יחד ולראות מה עובד יותר או פחות.מכאן - התפתחות לאנליטיקות, דו”חות וניתוחים מתקדמים.השירות ניתן כ-SaaS, אין Agent on premise שאוסף נתונים על השרתים של הלקוחות, אלא Tag -  האתר המארח מוסיף את קוד ה-JavaScript שעושה מעיין Bootstrapping לעצמו ומוריד את כל שאר הקבצים שצריך, מייצר Hooks לכל ה-Events שצריך על ה-Client ושולח את הנתונים (בצורה מדודה ומכווצת) לשרתים של Clicktale לעיבוד.רגע! התראת Privacy  . . . המשתמש צריך לאשר את כל הטוב זה?זה אכן נושא מאוד חם, והחברה כבר מימיה הראשונים עבדה בקו מחשבה שתאם את מה שאנחנו רואים היום (עם ה-GDPR למשל), ומקפידה למחוק מאפיינים של משתמש הקצה הספציפי - להתמקד רק במה שהמשתמש רצה ועשה ולא במי הוא בדיוק.הדוחות הסופיים הם סטטיסטיים, עבור KPI מוגדר - השימוש הקלאסי הוא לקחת פלחים מוגדרים (Segments)  וגנריים, ולהמשיך לפלח אותם לרמת דיוק שקיימת רק במוצר - משתמשים עם התנהגות שמצביעה על היסוס (Hesitation), מפות חום של אירועים שהסתיימו ב-Conversion לעומת כאלו שלא - ותוך זה להסיק מסקנות לשיפור ה-UI.שיפורי Funnel למיניהם - אבל גם למשל שיפור של תהליך הזנת פרטים עבור חברת ביטוח או אתרים למימוש זכויות וכו’.רק לשם ההדגשה - ההקלטה אינה של “וידאו” אלא של לוגיקת התנהגות המשתמש שעוברת בצורה דחוסה לניתוח, עם ה-HTML הספציפי שהמשתמש ראה וה-Events שקרו בזמן השימוש הספציפי.המידע טקסטואלי ועובד עיבוד - במוצר יש “נגן” שמציג את הנתונים כמעיין וידאו (מאפשר לנתח ולהתקדם או לחזור), אבל זו אינה הקלטה אלא הצגה של “סיפור דרך”.אחד הנושאים שעלו כפוטנציאל לשיחה בהכנה לפרק היה נושא ההתמודדות עם מגוון הדפדפנים וה-Events השונים. זה לא הולך לקרות בפרק הזה.מה כן? נתמקד ב-Stack הטכנולוגי שבו עובדים ב-Clicktale.החברה נוסדה ב-2006 - האפשרות הנגישה ביותר הייתה לעבוד עם NET. ועם #C (רפרנס מתחייב לחומוס מניפסטו של מייקל אייזנברג) - הכל היה בסביבת Microsoft (למעט אולי RabbitMQ - מוצר ישראלי אגב).המוצר התחיל כמעיין Freemium והתפתח לסדר גודל של עשרות אלפי לקוחות (SMB).השלב הבא היה עבודה מול סדרי גודל של Enterprise - וכאן נכנסו שיקולים כמו SLA של השרת מול הדפדפן של הלקוח, Up-time וזמינות של המערכת (היכן שאסור להחזיר הודעות שגיאה), רמות אבטחה הרבה יותר מחמירות וכו’ - כמו גם צידוק כלכלי למבט אל מחוץ לעולמות של Microsoft - והעלויות הנלוות אליהם עם המכפלות הגדולות של השרתים.מבחינת כמות אנשים - בשלב הזה היו בחברה סביב 100-120 עובדים (30-40 ב-R&D), ומבחינת שרתים מרכזיים סדר גודל של 40 (אולי לא נשמע הרבה, אבל הארכיטקטורה הייתה מונוליטית, והיה צריך פחות או יותר את השרת הכי גדול ש-IBM הסכימו למכור באותו רגע). זה כמובן השתנה משמעותית במעבר לענן (עם מאות ואלפי שרתים).אז ההחלטה לשנות את ה-Stack הטכנולוגי מובנת אבל כמובן שלא פשוטה - איך זה קרה?הכל התחיל עוד לפני שיפתח הגיע, ולא בהכרח בצורה פורמאלית קלאסית (Steering committee וכו’) אלא יותר יחד עם הצורך - עם לקוחות כל כך גדולים, חייבים להפריד מהמונוליט לפחות את רכיבי ה- Data pipeline כדי להתמודד עם ה-Spikes.בשלב הזה גם העלות של עבודה עם Microsoft באה לידי ביטוי לא רק כעלויות ישירות אלא גם בזמני תגובה ואיתחול של מכונות Windows, מעבר לתשלום הכספי המיידי.אפשר לפרק את המונוליט גם בסביבת Microsoft ועם NET. - אבל אז עדיין נתקלים במחסום העלות כשצריך לשלם על כל שרת בנפרד, וזה כבר לא משתלם (שוב - גם בזמני אתחול, up time, עדכונים . . .).עוד גורם - מבחינת Web Server ו-SLA של זמני תגובה, כבר הגענו לעשרות mS של זמן תגובה, ועבור לקוחות גדולים זה מתחיל להיות יותר מדי.האם מדובר רק במעבר טכנולוגי או בשינוי של ארכיטקטורת המערכת?גם וגם - בשלבים הראשונים היה ניסון לפרק את הקיים “ולחקות” כל יחידה בפני עצמה, אבל ככל שהביזנס גדל היה צריך לשנות את הארכיטקטורה על מנת לעמוד בעומסים ולהתמודד עם צווארי הבקבוק שהתגלו, כמו גם בהרבה דרישות עסקיות חדשות שיותר קל להתאים אליהן מערכת מבוזרת לעומת מונוליט (מבודד שינויים, מקטין סיכונים).סיכום ביניים - נקודת הזמן היא לפני כ-4.5 שנים עם ~120 עובדים מהם ~30 מפתחים, ~40 שרתים מפלצתיים ומונוליט מבוסס NET. וטכנולוגיות Microsoft ועם לקוחות שדורשים משהו שבנקודת הזמן הזו אי אפשר לתת - למה מחכים? אז מפרקים את המונוליט ומשנים טכנולוגיה . . . החלטה אמיצה. מה עכשיו?השלב הראשון היה חשיבה על הארכיטקטורה - והיה ברור שהמקום להתחיל הוא ה-Data Pipeline. היה תהליך מקביל עם ה-Database האנליטי, שעבר מ-SQL Server ל-Vertica.ההחלטה הייתה להתחיל עם Ingest - החלק שמקבל הודעות מה-Client (אחרי שגם את ספק ה-Cloud צריך לבחור) וצריך להעביר את המידע קדימה במינימום זמן.היו הנחות בסיס שבאו מלמעלה (יפתח . . .), כמו הכוונה לעבוד עם Linux, אבל יש גם הרבה החלטות מעבר, כמו למשל - איזו שפת פיתוח?ההנחייה הייתה לבחור משהו שיעבוד עם JVM, לאו דווקא ספציפית לכיוון Java אלא יותר מבחינת עושר הספריות הרלוונטיות - כשיש דרישה ל-Concurrency מאוד גבוה ו-Latency מאוד נמוך.לשלב הגמר הגיעו Golang ו-Scala - שנבחרה לבסוף.ההבנה הייתה שאם בוחרים ב-Golang ורוצים לממש את האלגוריתמיקה שלנו, עם עיבודים מורכבים על אלפי הקלטות, ב-Go - זה לא הולך לעבוד. זאת, לעומת Scala שאיפשרה את שני העולמות - כל מי שמפתח מעל Spark יודע כמה קל (ובמעט שורות קוד) יחסית לכתוב את האלגוריתם, ומצד ה-Concurrency יש גם את Akka (פלטרפורמה של Actor modeling שכתובה ב-Scala) עם ביצועים מדהימים.בזמנו רק Boost הציג ביצועים טובים יותר, אבל זה גם היה מאלץ לכיוון כתיבה ב-++C, ולא רצינו ללכת לשם, אז בחרנו ב-Akka HTTP (מה שהיה אז Spray).היינו צריכים גם לבחור Database, כי היה ברור ש-Database רלציוני הוא לא האבסטרציה המתאימה למה שאנחנו צריכים - אין שאילתות מורכבות ומצד שני יש דרישה ל-Write Throughput גבוה ו-Latency נמוך, אז חיפשנו מודל Key-Value שיאפשר יכולות כאלה.בחרנו ב- Aerospike - מעיין Redis על SSD שמגיע לביצועים מאוד גבוהים ולא מאבד מידע במקרה (חלילה) שנופל השרת (לא שהם נופלים, אבל בכל זאת).כיום גם Redis תומכים באותו הדבר, אז הבחירה היום עשויה להיות יותר מורכבתבחרנו בגרסה בתשלום של Aerospike ולא בקוד הפתוח - מנהל ה-DevOps הגיע מעולם ה - Ad-Tech ש-Aerospike מאוד נפוץ בו, והוא מאוד העריך את התמיכה שלהם על סמך ניסיון העבר. החלטנו שזה שווה בשיקולי עלות-סיכון, ובדיעבד מרוצים מההחלטה.אז התחלתם לפני 4.5 שנים עם החלק של ה Data Ingestion (הזרקת דאטה, יש מקומות שמכנים את זה Gateway - החלק שקולט את ה-Events מהלקוחות); בשלב הבא Data Processing (ובדרך שינוי Database) - ולאט לאט מפרקים את המונוליט ומשנים טכנולוגיה. האם המעבר שיטתי או שמתי שצריך לשכתב רכיב אז כבר עושים את זה ב-Scala?עבדנו בצורה שיטתית - המעבר לענן בפני עצמו גורר שינויים טכנולוגיים רבים, וגם כחברה פיתחנו במקביל מוצר נוסף, משלים למוצר הראשי, וגם גדלנו מבחינת היקף הפעילות - כל זה אומר שהיינו צריכים להיות מאוד זהירים ושיטתיים, ועברנו לפי הרכיבים והעדיפות (היכן שהתועלת תיהיה המשמעותית ביותר).בשלב הראשון צריך שכבת תאימות בין הקוד הישן (#C) לבין הקוד החדשנקודה כאובה, כי הספריות ב-#C (יחד עם האהבה אליה כשפה) שאמורות לתקשר עם Aerospike או Kafka, או אפילו Avro - הכל לא סטנדרטי וצריך לפתוח Bug לפרוייקט (שאף אחד לא יתקן לעולם . . .)הפקנו מכך הרבה לקחים - בהמשך העדפנו לשכתב רכיב ל-Scala (או Java) ולא לעבור את זה שובהרבה מזה נובע משימוש - יש יותר חברות שעובדות עם JVM ופחות עם NET., והמוטיבציה לתחזוקה של הספריות גבוהה יותר.איך מתנהלים מול העובדים? הרבה מתכנתים חזקים ומנוסים, שעכשיו מזיזים להם את הגבינה (ומישהו צעיר בצוות יכול פתאום להכנס הרבה יותר מהר ולקחת להם את המקום)התהליך היה משותף, אנשים ראו את היתרונות (וגם את הסעיפים החדשים ב-LinkedIn שיהיו להם שימושיים לקריירה . . .).הפידבקים על הקורס “מבוא ל-Scala” שארגנו היו לא משהו, לא כי המרצה לא היה טוב אלא כי החבר’ה כבר למדו לבד ועברו את שלב המתחילים. קיבלו פיצוי בדמות קורס מתקדם של Akka, ושם הם כבר קיבלו הרבה ערך מוסף.בחברות יש מפתחים שעובדים על ה-Business Logic, וגם את אנשי התשתיות (הפיסיות) שתומכים בהם - איפה הם היו בתהליך?מבחינת תשתיות תוכנה - לא היינו מספיק גדולים בשביל להקדיש צוות רק לתשתיות, אז אלו בעצם אותם אנשים.יחד עם זאת - יש את צד ה- DevOps והפלטרפורמה שעליה רצים, וכאן כמובן היה שינוי ותהליך למידה אולי אפילו יותר קיצוני, עם עושר טכנולוגיות שהם היו צריכים ללמוד.כמה שניסינו לצמצם את ה - Stack הטכנולוגי, עדיין איכשהו על כל טכנולוגיה בעולם הפיתוח צריך 3-4 בעולמות ה - DevOps.זה אחד מיתרונות המקצוע - דורש הבנה של המון טכנולוגיות והמון שינויים.התחלנו עם בערך 12 אנשים בקבוצה, ובהמשך התהליך כבר גדלנו ל - 24-25, כשהגיוסים החדשים כבר היו של אנשים שמכירים את הטכנולוגיות החדשות והוסיפו ניסיון.מעיד בדיעבד גם על נכונות הבחירה והכיוון, כי בשוק יש הרבה חברות שעובדות באותו Ecosystem, מה שתמך במעבר ואפשר את “ייבוא” הניסיון מבחוץ.אז איפה אתם היום?מבחינת גודל החברה - ב - Slack יש 220-230 אנשים, הרוב בישראל ויש גם בארה”ב ובאירופה (בעיקר אנליסטים, מכירות וכו’).גוף ה - R&D כבר בסדר גודל של 60-70.מבחינת Data - כבר עברנו את רף ה - Petabyte (אזהרת אנכרוניזם - מי ששומע את הפרק כמה שנים אחרי ההקלטה כנראה יגחך) - גם האנליטי וגם מה שמשמש לדוחות.מבחינת Throughput - ה - Pipelines כבר יודעים לטפל במעל 10Tb לשעה, ואפשר להגיע להרבה יותר (לא נדרשנו מעבר לזה בינתיים).מבחינת לקוחות - ירדנו לחלוטין מאלפי ה - Freemium לסוגיו, ועובדים עם סדר גודל של כ - 250 ארגונים (Enterprise), שכל אחד הוא שם גדול כלשהו.מבחינת שרתים, הכל אלסטי אז זה משתנה - בשיא מגיעים לכמה אלפי שרתים, בשפל מדובר בכמה מאות.הנטייה היא להשתמש ב - Instances קטנים (רצים על AWS), גם על מנת לחסוך בעלויות.מבחינת SLA שהלקוחות דורשים - עם Spray Web Server ה - Latency הממוצע הוא סביב 1-2ms, ו -  Aerospike מאפשר פחות מ - 1ms בכתיבה.משיחות עם מפתחים שעובדים היום ב - Scala, יש תחושה שהשפה קצת “נרדמה” - האם שוב מדגדג לבחון שינוי?מי אמר Golang?!אצל המפתחים יש דיונים בנושא, ויש כאלה שמשחקים עם Clojure או Lisp - כחלק מהנטייה הטבעית של מפתחים לחפש את מה שמעניין וחדש.מנקודת המבט של שחר - האם חסר משהו? לא נראה ש - Scala הלכה לאחור מבחינת מענה לצרכים, כרגע זה בעיקר נושא לשיחות בארוחות צהריים.השינוי לא קורה ביום אחד (אולי אצל אחרים, בדר”כ לא . . .) - כמה שורות NET. עדיין יש?יש עוד חלקים כאלה - ב - Data Pipeline יש חלק אחד כזה, שאין מוטיבציה להעביר כי הוא עובד בעיקר Offline (דגימה), ועובד מצויין. המוטיבציה הנראית היחידה להעביר זה אם רוצים שאף אחד לא ידרש לדעת NET.השפה מאוד קריאה ונוחה, כך שלא ממש דחוף לאף אחד.יש עוד כמה “זנבות” כאלה, אבל לא משהו שמפריע.ועכשיו - טיפים של אלופים! אם מסתכלים על חברה עם כמה עשרות מפתחים, מה (בראייה לאחור) כדאי לעשות?להקפיד על Monitoring ו - Alerting - להבין איך בדיוק המערכות עובדות, כי גם אם עשיתם בדיקות עומסים, ב - Production זה יראה אחרת.ה - Data בשלב ה Production לעולם יהיה שונה ממה שניתן לערוך עבורו סימולציה (ההתנהגות דינמית ויש המון פרמוטציות) - חייבים למדוד.הרצה Side-by-Side, ומעבר מדורג לטכנולוגיה החדשה כשרואים שהכל יציב.קרה שחזרתם אחורה? לא זכור משהו ספציפי, דווקא עם Kafka שמאוד נפוץ וברור יחסית - כשהיו בחירות לא צפויות פתאום קרו דברים שלא צפינו, ולפעמים גם חזרנו אחורה עם חלק מהקונפיגורציות.להכיר את ה - Data . . . כל מקרי הקיצון, כל סוגי המידע שיכולים להגיע לשדות השונים, מה יכול להגיע חסר, היחסים בין חלקי מידע, השפעות על חלקים אחרים במערכת (גם שלושה שלבים לאחר מכן).אל תסמכו על אף אחד או על מה שקראתם בבלוגים . . . ה - Spec לפעמים משקרלפעמים הופתענו לטובה ולפעמים לרעה, כשלא ברור איך הגיעו לתוצאות הללו (ב - POC זה לא השתחזר. . . ).מקרה חיובי - Spray, שאיתו הצלחנו להוציא יותר מ - 10K בקשות לשניייה, עם ליבה בודדת של CPU, לאחר שממה שקראנו הציפינו להרבה פחות.טיפ כללי - כשבוחרים טכנולוגיות, חשוב להתרכז במשהו חדש, אבל לשים לב אולי לא בהכרח להכי חדש, כי כן צריך Scale מסויים שיבטיח שמספיק אנשים “התגלחו” קודם על הטכנולוגיה.לדוגמא - חברה גדולה יכולה להחזיק מומחה Angular, לחברות יותר קטנות לא תמיד יש את הפריבילגיה למעטפת שיכולה להתמודד עם ה - Disruption, וצריך סבלנות עם הגרסאות החדשות.הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

פרק מספר 365 (מספר קוסמי!) של רברס עם פלטפורמה - קרבורטור מספר 26: אורי ורן מארחים את נתי שלום (היזם של חברת Cloudify) לשיחה התקופתית על קוד פתוח, עננים, תשתיות ואירועים מהתחום מהזמן האחרון.קצת רקע להיום: ב - 11 למרץ 2019 פורסמה הודעה של AWS על התאגדות משותפת עם מספר חברות (בינהן Expedia ו-Netflix), על מנת לקחת מוצר בשם Elastic Search (חברה שהיזם שלה ישראלי, תזכורת לפרק 362 עם אורי כהן, וגם התגובה של שי בנון המייסד) וליצור עבורו מודל הפצה חדש (Re-distribution), מה שמרעיד את אמות הסיפין בתחום ומעורר לא מעט שאלות.נתי גם אמר את זה קודם . . .הנושא הציף קודם כל את הבלבול שקיים סביב המודל העסקי של חברות קוד פתוח והאופן שבו הן מייצרות רווח - נכון עבור Elastic אבל באותה מידה גם עבור Redis או GitHub וכו’.כל המוצרים של החברות הללו מגיעים מחברות ממומנות ולמטרת רווח ישיר, בשונה למשל מפרויקט כמו Kubernetes, שגוגל מעודדת על מנת לעודד צריכה של Google Cloud (ומשם לייצר רווח “משני”).יש מספר דרכים לרווח ישיר ממוצר קוד פתוח - רישיון שימוש (Subscription license)שירות כ-SaaS (ותשלום לפי צריכה)שירות מנוהל (Managed Service) - דומה ל-SaaS, רק שיש אפשרות גם להריץ בעצמךתשלום על תמיכה ו-Extra Featuresנקודה עדינה, כי יש גבול דק שקל לעבור ולהפסיק להיות “באמת” קוד פתוח. כל ה-API למפתחים חייבים להיות פתוחים, אבל תחומים של Clustering או Security למשל כבר נחשבים כ”איזורי מוניטיזציה” - זה כבר לא POC או פיתוח אלא שימוש משמעותי שמצדיק תשלום.ההבדל המשמעותי לעומת “קוד סגור” הוא היחס שבין הספק ללקוח - צריך לשלם, אבל לא מיד ברגע שנוגעים במוצר אלא רק כשיש ערך ברור.חשוב לשים לב שגם צד הלקוח מעוניין הרבה פעמים בתשלום כלשהו עבור שימוש משמעותי - יוצר מחוייבות לתמיכה (או לפחות תחושה כזו) ואומר שיש מישהו מאחורי המוצר שיכול לתמוך במקרה הצורך.זו מערכת מבוססת אמון (Trust system) - ויש מגוון סוגי רשיונות שמגדירים מה מותר לעשות עם החלק הפתוח (החינמי)הרשיון “המתירני” ביותר נקרא Apache 2.0, שמאפשר כמעט הכל (כולל re-distribution) והרבה ארגונים משתמשים בו, גם מתוך חשש מרישיונות כמו GPL למשל, שאומר שאם מבצעים שינוי בקוד חייבים לשתף גם אותו (מה שעשוי להיות קשה לשליטה ובעייתי באופן כללי לארגונים גדולים).למיטבי לכת (ושמע) - היה פרק שלם גם על זה עם עו”ד(!) דביר גסנר (ב-2012, ועדיין), ועוד אחד על רשיונות קוד פתוח (פרק 211 מ-2014), וגם זהר זקס הרחיב על הנושא בפרק 317 על Zusammen. הרבה שיעורי בית.בשורה התחתונה - חברות פחדו ממצב בו מפתח בודד יעשה שימוש בקוד עם רישיון שמעבר ל-Apache 2.0 (או MIT License שהוא די מקביל) ויחייב את החברה לשיתוף שהיא לא יכולה לעמוד בו.השוני הגדול הוא בעיקר בזכויות ההפצה (Re-distribution) ושימוש כ-SaaS.העיקרון הבסיסי הוא שהפרויקטים הללו דורשים הרבה מאוד השקעה, חדשנות וטכנולגיה, ועומדות מאוריחהם חברות גדולות שבסופו של דבר צריכות מודל עסקי על מנת להתקיים ולהרוויח (ולהנפיק…).לא צריכה להיות סתירה בין זה לבין טובת המשתמש, שעדיין נהנה ממוצר באיכות מאוד גבוהה בחלק הפתוחשונה מפרוייקטים שמבוססים לחלוטין על  תרומות קוד של משתמשים, מה שעובד לרוב רק כשיש חברות שמאגדות את הפרוייקט על מנת להפיק ערך באופן אחר (שוב - דוגמת Kubernetes ו-Google).אז בחזרה לשאלה המקורית -  למה רעדו אמות הסיפין?המרכיב הראשון הוא עניין האמון - ברגע שיש שימוש משמעותי במוצר צריך להתחיל לשלם. מה זה “משמעותי”? בדיוק . . .אם אני עושה שימוש משמעותי בקוד הפתוח, אבל גם מאפשר להשתמש בו בחינם (או לקבל תמיכה בחינם וכו’), נוצרת פגיעה בחברה שפיתחה את הקוד, ולא נהנית מרווח בשלב בו הוא הופך ”לגיטימי”אם נוסף על כך את העובדה שזה קורה בפרויקט שבו לא תרמתי למוצר מלכתחילה, ורק אפשרתי שימוש משמעותי בחינם - נוצר משבר אמון עמוק.אז AWS.משמעות ההודעה של AWS היא שעבור מוצרי קוד פתוח שהם לא באמת תרמו לפיתוחם, הם חותכים את קווי המוניטיזציה - על מנת להנות מהשימוש הרב בהם (להנות מהרווח הנגזר מהשוק שגדל, בלי להשקיע בשלב הראשון של יצירת ופיתוח השוק).נותנים שירות ותמיכה לחלק החינמי של השירות - ובפועל מתחרים בחברה המפתחת על התמיכה במוצר (החינמי) שלה, אותה תמיכה שהרווח הפוטנציאלי ממנה היה הבסיס והתמריץ לפיתוח.הדרך של החברה להגיע למשתמשים הייתה, למשל, לאפשר שירות במודל SaaS על התשתיות של AWS (שמרוויחה כבר בשלב הזה, אבל זה ממודל אחר), ולהרוויח מתמיכה. בשלב הזה נכנסת AWS שוב, ומתחרה בחברה המפתחת על תמיכה במוצר הקוד הפתוח שלה.מעבר ל- Elastic Search היו מקרים דומים גם עם MongoDB ו - Redis, וגם עם InfluxDB - שהגיבו ע”י שינוי מודל הרשיונות שלהן. יש הרבה דוגמאות כאלה עם AWS, שמאוד עקבית במדיניות הזו.התגובה הסטנדרטית של AWS במקרים כאלה היא שהם רוצים לתת שירות טוב יותר למשתמשים - ועבור הלקוחות יש לכאורה שירות יותר טוב במחיר יותר נמוך.האם באמת יש כאן Win-Win? שאלה טובה, נחזור אליה.אז הכל היה כבר קודם - מה קרה עכשיו ששונה?נחזור לכותרת של הפוסט - “Keeping Open Source Open – Open Distro for Elasticsearch”נכתב ע”י Adrian Cockcroft, ארכיטקט Cloud ב-AWS, בעבר גם ב-Netflix, ביקר בארץ באמצע מרץ (Keynote speaker ב- AWS Summit 2019, אפשר גם להשלים בוידאו).מאז היו עוד פרסומים.נתפס כמעיין “הרצחת וגם ירשת?” . . . יש כאן  מתקפה על חברות הקוד הפתוח בטענה שהן לא באמת מספקות קוד פתוח (כי הן מרשות לעצמן לרצות להרוויח), והצגה של AWS ככזו (בזמן שרוב המוצרים שהיא מפתחת בעצמה אינם בקוד פתוח כלשהו).הטענות שעולות בפוסט הן ש-Elastic במשך הזמן הוסיפו סעיפים שהופכים את הקוד ללא באמת פתוח, יחד עם הדוגמא של Java (סיפור ה-End of Life מבחינת אורקל, כש-AWS “ראו את טובת המשתמשים” והחליטו להמשיך ולתמוך).בשורה התחתונה - לא רק לקחו “פרי בשל” של חברה אחרת, אלא גם הטיפו מוסר. אין כאן שום דבר לא חוקי, אבל נראה לא משהו בכלל.הסכנה לטווח הארוך היא פגיעה בשוק הקוד הפתוח לטווח הארוך - משקיעים מתחילים לשאול איך (ואם בכלל) אפשר למנוע מ-AWS לעשות מהלכים כאלה בעתיד?התשובה הפשוטה - להשתמש ברשיונות פחות פתוחיםרואים את זה כבר עם Elastic ועם MongoDB, שמתחילות להגן על עצמן מפני הפרות אמון כאלו, מה שהופך את הדיון לכללי יותר, עבור כלל התעשייה: איך בונים יחסים של Win-Win בין ספקי הקוד הפתוח לספקי תשתיות הענן (Cloud Providers)?האם הכיוון הוא חרם צרכנים? - מי בדיוק יחרים? . . .אם חברות הקוד הפתוח לא ישתמשו ב-AWS, הם יעשו את זה בעצמם. נראה ש-AWS מפסידה בעצמה כי ככל שיותר חברות קוד פתוח ישתמשו בתשתיות של AWS כך היא תרוויח.זו לא באמת שאלה של מי צודק, אלא שאלה של טובת הצרכן לנוכח ניגוד האינטרסים.שווה לשאול מה קורה עם מוצרים שאינם קוד פתוח - תוכנות Microsoft למשל.כאן ב-AWS ידעו למצוא מודלים של Win-Win עבור כל הצדדיםלכאורה ההבדל היחיד הוא שבמקרה של קוד פתוח יש פירצה משפטית (או מערכת מבוססת אמון) שמאפשרת לעקוף את זה, וניצלו אותה.יכול להיות שהדרך היא להסתכל באותה צורה גם על חברות קוד פתוח וגם על חברות “מסורתיות” (ראה מקרה Oracle).ההבדל הוא שבמקרה של קוד פתוח, AWS לכאורה מספקים את השירות בחינם (הם עדיין מרוויחים על התשתיות).כל זאת - בזמן שעל AWS רצים יותר שרתי Windows מכל מערכת אחרת (ע”פ Adrian Cockcroft ב-AWS Summit בתל אביב), וכולם מרוויחים יפה.בזמן שעל Azure רצים עם Linux . . .כל ההבדל הוא הפירצה, והיכולת לנצל אותה.אין משקיע שישקיע בחברה ללא כל סיכוי לרווח כלשהו. המודל אינו התנדבות מלאה (לא מודל בר-קיימא בכל אופן).זה בסדר להשתמש בקוד פתוח ולא לשלם, וזה אכן נכון ל-90% מהמשתמשים. השאלה מה קורה כשמגזימים.אם למשל Outbrain משתמשים ב-Hadoop בלי לשלם (לשימוש פנימי), זה כנראה בסדר - כי הם לא מוכרים את המוצר, ולא מתחרים ביצרן - וזה גם כנראה נלקח בחשבון במודל העסקי של היצרן.זה לא המקרה עם AWS, וזה ההבדל הגדול - זה לא שימוש פנימי אלא תחרות ביצרן: הצעה של חלקים גדולים מאותו שירות לאותו בסיס לקוחות, עם התשתיות האדירות של AWS ובלי הוצאות (וסיכוני) הפיתוח.המעניין הוא ש Adrian Cockcroft מתייחס לזה, וטוען ש-AWS עושה שירות טוב ליצרני הקוד הפתוח, בכך שהיא מעניקה מעיין “חותמת כשרות” למוצר (ותורמת לעלייה משמעותית בשימוש בו).צודק - החברות אכן לא נפגעו כלכלית בשורה התחתונה, לפחות כרגעפחות - אם כל ספקי הענן יתנהגו כמו AWS, חברות כבר ל יוכלו להיבנות על פי אותו מודל עסקי שעליו נבנו Elastic ודומיה (מי ישקיע בזה בכאלה תנאים?), והשוק יתייבש. בראייה ארוכת טווח זה כבר לא טוב גם למשתמשים של AWS.אם מסתכלים על חברות ענן באופן כללי, נראה שיש הבנה והכרה בערך של קוד פתוח - רואים את זה מ-Google כבר לאורך הרבה זמן, ו-Microsoft בשנים האחרונות (כולל הרכישה של GitHub), יחד עם מלחמת Android-IOS התמידיתבסך הכל, שנת 2018 הייתה טובה מבחינת ההכרה בערך חשיבות הקוד הפתוח - ההנפקה של Elastic, הרכישה של GitHub, הרכישה של Red Hat, ועוד.אין (או לפחות לא אמור להיות) קונפליקט בין הצורך של המשתמש לבין היות המוצר פתוח - אנחנו לא רוצים להינעל על ספק, ולא רוצים לעבוד עם קופסאות שחורות.יצא פרק קצת פוליטי (לכבוד הבחירות?!), אבל אנחנו אופטימיים  הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

רן, אלון, ודותן בפרק מספר 57 של באמפרס (364 למניין רברס עם פלטפורמה) - סקירה של טכנלוגיות ודברים מעניינים האחרון, נכון ל-1 באפריל 2019. מתחילים בגדול - מכירים CAP Theorem? ההנחה עד היום הייתה שבמערכות מבוזרות אי אפשר לשמור במקביל על Consistency, Availability  ו - Partition Tolerance, אלא לכל היותר על 2 מתוך ה-3 בו זמנית. עכשיו מגיעה תפנית בעלילה,  דווקא מכיוון הפיסיקה התיאורטית - מדענים פרסמו ניסוי מחשבתי, שאומר שבמידה וניתן לעבור את מהירות האור,  ניתן לשמור על שלושתם במקביל!כיוון מעניין, בעיקר מבחינת מחשוב קוונטימה זה אומר לגבי Spanner? לא צריך את כל השעונים האטומיים? . . . לא, צריך רק לעבור את מהירות האור וזהו.למתי מתוכנן? צריך לבדוק עם איינשטיין (לא של Salesforce - אלברט עצמו, כי אם כבר עוברים את מהירות האור יש מצב שאפשר לחזור אליו).בהמשך לזה - באמצעות ענן של Quantum Computing, ולמשך חלקיק שנייה, נראה שהצליחו להפריך את CAP Theorem, ובתהליך נוצרו חלקיקים חדשים, שזכו לשם CAPP - CAP Particles.המאיץ ב-CERN מכוייל עכשיו כדי לאתר את החלקיקים החדשים - העולם הפיסי מתחבר לעולם התוכנה, וזה כבר לא רק ניסוי מחשבתי. המודל העסקי של Google בסכנה (בחמישים השנים הקרובות)?חדשות מכיוון פייסבוק והתשתיות (להקה חדשה?) - למי שזכור את ה- HipHop compiler, שנכתב ב-Facebook ומקמפל קוד PHP ל ++ C (קוד מאוד מהיר) - אז עכשיו הוכרז על פרויקט חדש בשם HipContain.מבטיח תכונות חדשות כמו Security ו-Startup Time מהיר (sub-ms), מזכיר קצת את ה AWS Firecrackerאז יש Container Engine ב-PHP - נראה שלשם הולך העתיד, אין ספק.קצת חדשות מהארץ  - בזק מכריזים על התשובה שלהם ל-S3: שירות ענן חדש בשם B4 (אין קשר לסובארו) Bezeq is a Better Bang for the Buckלא ברור לגמרי לאן זה מכוון, כנראה בעיקר לשוק הבינלאומי - דותן ניסה וננעל כיוון שה-Region לא התאים, אלון ניסה עם VPN ודווקא כן עבד. לגידי גוב בטוח עובד.נראה שלבזק יש סכסוך כלשהו עם הרשויות האמריקאיות על רקע האמירה של הנשיא טראמפ על הכוונה לחוקק חוק שאוסר על אחסון מידע מחוץ לגבולות ארה”ב.הפתרון עשוי להיות ספינה עם קונטיינרים ועליהם הדאטה, כך שזה לא שייך לאף מדינה  - אחרי ספינות ההימורים והאלכוהול, עכשיו יווצר שוק של ספינות דאטה, רעיון מהפכני לכל הדעות.בהמשך לאייטם של רן על AWS שמאפשרים להשהות workload ב-EC2 (באמפרס 56) - הפיצ’ר הורחב, ומאפשר לעשות את זה לכל הענן.למה זה טוב? ניתן לממש ענן שומר שבת! הלקוח הראשון שמימש הם B&H, שעוצרים עם כניסת השבת ומחזירים את הענן מאותה נקודה בדיוק בצאת השבת.עובד עם לו”ז כללי, לא ממש עוקב אחרי הכוכבים - אינטגרציה פשוטה עם השירותים של Amazon, בלי צורך לשנות את הקוד (בדיוק רצה לולאות For? היא תעצור, ותמשיך מאותה נקודה בצאת השבת).רעיון לשיפור - להגדיר דרגות חומרה על פי ספירת כוכבים להגדרת מועד צאת השבת המדויק (API פשוט): יש כאלה שיסתפקו בשלושה כוכבים, ומי שבטח ירצה ללכת על בטוח ולא לחדש את הענן לפני שזוהו חמישה כוכבים, וכו’. נפנה לרב ונבדוק.אגב - זה לא רק לשבת: מתחילים לראות בלוגים שמדברים של מימוש אפשרי עבור Work-Life Balance: הפיתוח עוצר בשש בעבר וממשיך רק בבוקר. הימור שלנו - לא ירחק היום שבו האיחוד האירופאי יעביר חקיקה בנושא.פרויקט קוד פתוח חדש ומעניין, שהתחיל כפרויקט צד של יוצאי גוגל: מימוש מנוע חיפוש עם יכולות דומות לאילו של המנוע של גוגל (גם אם לא באותו Scale) - והכל ב-Bash (מעבר לדברים הבסיסיים שמותקנים על כל Linux).דוגמא מאלפת לאילו דברים יפים / נוראיים אפשר לעשות עם Bash.לא שימושי בשום צורה - לא ביצועים ולא Scale - ועדיין הוכחת יכולות מרשימה.סביר להניח שהתחיל כהתערבות בסגנון “אין מצב שאפשר לממש מנוע חיפוש ב-Bash” והרבה אלכוהול. . .עדיין בסביבת Google  - כנראה ש Kubernetes הוא ה Orchestration Engine הנפוץ בעולם, ועדין אחד הקשיים העיקריים של משתמשים חדשים הוא, ובכן - הגייה נכונה של השם . . .הרבה נוטים להגות Kubernetecs (קוברנטיקס, מקרה מתועד אפילו באחד הפרקים האחרונים כאן), כנראה שזה מתגלגל יותר טוב על הלשון.כמו כל חברה רצינית, בגוגל ביצעו Usability testing, והגיעו למסקנה שהקהל כנראה צודק ושהגיע הזמן לשנות את השם רשמית (משהו בסגנון “עגבניה היא ירק כי הציבור חושב ככה”) - מעכשיו יש לומר Kubernetecs, ותוך דור או שניים זה יהיה פשוט גם למי שכבר התרגל להגייה הקודמת.אבל זה לא סוף הסיפור - עכשיו צריך לשנות את הקוד בערך בכל העולם, ומסתמן שהקהילה מתפצלת בין אלו שיש להם זמן לזה ואלה שמעדיפים לא לשנותכל מי שלא מפחד לשנות ויש לו תשתית בדיקות מלאה עובר ל-Kubernetecs, ויש הרבה שממשיכים לתחזק סביבות עם Kubernetes. בהצלחה לכולם.ועוד תת פיצול - אלו שמדגישים את השינוי עם הדגשת ה-C החדש Kubernetecs - ואלו שלא.וכמובן שמישהו כבר מיהר וקנה את את הדומיין Kubernetic - נראה שצפה את השינוי אבל טעה באיות.מה כבר הבעיה לשנות את הקוד? ב-Go לא בעייה, ב-Rust לעומת זאת . . . תיכף נגיע לזה. לא קשה תיאורטית, אבל פרקטית זה יותר מורכב.ואם כבר חזרנו לויכוח העתיק של Rust vs. Go - יכול להיות שהידיעה הבאה תבטל את הויכוח: יש compiler מ-Go ל-Rust ולהיפך (Transpiler).יש את Rustiler שמקמפל Go to Rust ויש את Gopiler שמקמפל Rust to Go.במה זה כתוב? נשאיר כתרגיל לקורא . . . תבדקו לבד.תופעה מעניינת - כל מעבר כזה יוצר אופטימיזציה שמתבטאת בקובץ Binary קטן יותר בשפת היעד!גורר תופעה שבא אנשים משתמשים ב-Transpiler לכיווץ.אם מריצים המון פעמים (Go-Rust-Go-Rsut-…) נוצר Binary file בגודל 0kb.החוכמה היא לעצור רגע לפני ה-0, ולקבל את הקובץ המינימלי השימושי - פריצת דרך מדהימה.חדשות נוספות מעולם ה-Google AutoML (שאכזב קצת את אלון אבל בכל זאת נחמד) - עכשיו יש את ה-AutoCode:אין מה להשקיע בצורה שבה כתוב הקוד - רק צריך להכין משהו בסיסי, להעלות ל Google Functions (הגרסא של Google ל - Lambda של AWS), ומשם כבר יש אופטימיזציה לקוד יעיל, Bug-proof והרבה יותר הגיוני.יכול לקחת כמה דקות (תלוי בגודל הקוד ובלוגיקה), אבל עובד מעולה. גוגל מדברים על שכתוב של הקוד שלהם עם AI.מזכיר אייטם קודם שהיה כאן על כלי של פייסבוק לתיקון קוד אוטומטי (Getafix) - אבל לא בצורה הזו (כמו Lint למשל), כנראה שזו ההשראה. אפשר להירשם באתר ולחכות (כרגע על Alpha, לא זמין לכולם).וגם Angular 9 עומד לצאת - והפעם עם מהפכה תשתיתית: ה-Framework כולו עובר ל-Dart. כן.מבחינת ביצועים זה מטורף.התרגלתם לכתוב Frontend ב-JavaScript? כולם ככה - ועכשיו עוברים.כבר הספדנו את Dart כמה פעמים - ניסה להיכנס לדפדפנים, היה Transpiler ל-JavaScript, אבל באיזשהו שלב Google ירדו מזה ועברו ל Flutter - ועכשיו זה חוזר שוב.מעניין האם יהיה איחוד, עכשיו כשיש בסיס טכנולוגי אחיד - משהו בסגנון React Native מבוסס Angular עבור מובייל. גאוני - Flutter ו-Dart יחליפו סוף כל סוף את JavaScript ותיהיה שפה הגיונית.דרמה! שמעתם על המהומה סביב הגירושין של ג’ף בזוס? לא קשור ישירות אלינו ולא לרמת פודקאסט איכותי כמו רברסים, אבל אתם מוזמנים בכל זאת לעבור על המכתב המדהים של ג’ף בזוס, אבל בשורה התחתונה - הם מתגרשים, ומסתבר שהיה הסכם שבמקרה כזה צריך להחליט מה קורה עם Amazon ועם AWS.מסתבר שההחלטה היא לפצל את החברות - AWS עוברת לידי אשתו מקינזי, ו-Amazon נותרת אצל ג’ף.בתור ה-CEO החדשה של AWS, נראה שהמהלך הראשון של מקינזי יהיה להגדיל רווחיות ע”י העלאת מחירים (ופה זה כבר כן נוגע לרובנו).בתגובה - Amazon החליטה לרדת מהענן. כן.תכל’ס היא כנראה אף פעם לא הייתה שם לגמרי אף פעם - יש הרבה שירותים של Amazon שיושבים על הענן, אבל זה בעצם עוד לקוח Enterprise גדול של AWS עם מעבר איטי, שעכשיו עוצר ועוזב. לא יקרה ביום אחד אבל זה הכיוון.יש כבר כתבות שמדברות על פנייה של מארק צוקרברג לג’ף בזוס עם הצעה לארח את Amazon על הענן של פייסבוק, שעד עכשיו לא פתחו את שירותי הענן שלהם החוצה.ואיך לא - Werner Vogels מגיב בטוויטר (האייטם הקבוע בכל פרק של באמפרס) ואומר שהוא לא יודע על מה מדובר - הוא בחופשה על מנת לקדם את הליכי הגיור שלו ולא מכיר את הפרטים. נראה שהוא גם לא מרגיש בנוח עם זה על רקע תהליך הגיור ועשרת הדברות וכו’.האם קשור לענן שומר השבת? יש מצב ששווה להגיע אליו עם Pitch.וורנר מתארח ברברסים עם כיפה וציציות? כבר קרו דברים . . .חזרה מהצהוב לחדשות רציניות, והפעם בישראל -חיל האויר הישראלי עולה לענן: בעקבות הסטורית התקלות של מטוסי הF35 בארה״ב — פרויקט התוכנה היקר בעולם, הוחלט בחיל האויר הישראלי, כחלק מפרויקט ההשבחה, להעביר את כל השירותים החישוביים של המטוס לענן במקום על המטוס עצמו. לצורך כך נבנית תשתית תקשורת לווינית חדשנית שלא הייתה קיימת בעבר, כולל תשתיות P2P בין המטוסים (לא רק לווייני).חיל האויר כבר החל בגיוס של אנשי דאטה תחת הסיסמה: ״הטובים לדאטה״.מפקד חיל אויר בתגובה: ״הטייסים והטייסות שלנו יעידו שהמטוסים שלנו טסים מעל העננים ובין העננים כל הזמן. זה היה רק עניין של זמן עד שאנחנו נשים את המוח של המטוס גם בענן. אנחנו מאוד גאים להיות החלוצים בתחום.״אבחנה מעניינת - אם כבר המטוס בעננים זה לגמרי הגיוני שגם הדאטה יהיה שם, הלוקאליות הרבה יותר גבוהה וה-round-trip יותר נמוך: במקום לרדת לקרקע וחזרה נשארים בעננים.מדהים שזה נחשף ולא נשמר בסוד - כנראה מעיד על עד כמה PR חשוב על מנת להשיג את הכשרונות בתחום, אחרת לא רואים סיבה לפרסם משהו כל כך סודי וגדול.העתיד בעננים, וזה כנראה גם הרבה יותר מאובטח. צריך רק לשנות את השם לחיל האוויר והעננים והחלל. והירח.בשלב הבא - חברות מסחריות מפריחות כדורים פורחים עם ענן מחשוב בפנים?אז Data center שקוע בים כבר יש, Data Center ב-containers על אונייה זה אייטם טרי מהיום, ועכשיו אלון מציע כדורים פורחים. לכו על זה.זוכרים את עסקת GitHub - Microsoft? אז זה היה כנראה עניין של זמן, אבל עכשיו GitHub הורגת את אטום, ומעבירה את כל מפתחי אטום ל vscode. משיחה פנימית עולה, שכל המפתחים של אטום שעברו לפתח את vscode מחוייבים לעבוד בווינדוס 10 על… NotePad (!) לפחות כמה שעות בשבוע. מאוד תמוה, נשמע כמו סוג של עונש.מייקרוסופט בתגובה: ״אנחנו רוצים שירגישו את הכאב, וככה יעזרו לנו לבנות מוצר יותר טוב״אחד מהמפתחים בתגובה: ״סתם מתנכלים לנו כי היינו העורך היותר טוב״.מייקרוסופט כנראה צודקים - אם הם לא יפתחו על Win10 איך הם ילמדו? אמנם מדובר באנשים בוגרים, אבל זה רק כמה שעות, לא נורא. קנו אותם - שיתנהגו בהתאם.אולי עכשיו נראה NotePad משוכלל, וזה יהיה הדבר החדש - או שנבין מי הם משתמשי Win10.זה גם הסבר אפשרי לזינוק בגרף המתשמשים?חדשות ממלחמת וואטסאפ-טלגרם: לאחרונה טלגרם תפסה תאוצה ונגסה בשוק של וואטסאפ בגלל המודעות להצפנה וההייפ סביב הקריפטו. בתגובה, בשנה האחרונה וואטסאפ הקימה צוות מומחים שהצליח לפרוץ את ההצפנה של טלגרם וגם של וואטסאפ עצמה.היום וואטסאפ הודיעה גם על הפריצה החסרת תקדים - וגם על הפתרון: הם הולכים לתרגם את האנגלית קודם לנאוואחו (בדומה לצבא ארה”ב במלחמת העולם השנייה) ואז להצפין, מה שלטענתם יתן להם יתרון תחרותי ענק כי דוברי הנאוואחו האחרונים בעולם הם כיום עובדי וואטסאפ.מי אמר Job Security? מי מרים את הכפפה ועובר לרש”י?אולי זה הפתרון לשבירת ההצפנות ע”י מחשוב קוונטי? זה הזמן ללכת ל-npm וליצור חבילות קידוד מנאוואחו, הזדמנות מטורפת. רק לזכור להכין את ה-Backdoor.לינוס טורבלדס (Linus Torvalds) בארץ!תוך ההפסקה מלינוקס (והתקפי הזעם והחזרה בחצי כח), לינוס חוזר קצת שונה - והוא עושה טור בעולם עם סדנאות שליטה עצמית לגיקים -  ועכשיו גם בתל אביב!הכותרת של הסדנה: ״אין אנשים רעים. יש רק קוד רע״ברכות לקופיריייטר, יש מצב לאופנה של Bumper Stickers?מיקום הסדנאות עדיין לא פורסם - אולי במצפה רמון? או בגוגל קמפוס (Do no evil)?נטפליקס חוסכים עלויות - נטפליקס הודיעה שכדי לחסוך עליות ולמקסם רווחים הם עוברים לטורנטים. מהיום נטפליקס יפרסמו סרטים באתרי טורנטים רגילים, לצד הלא חוקיים. הפורמט החדש: A.Star.Is.Born.1080p-WEB-DL.Certified.2019-NETFLIXבפורום של נטפליקס אחד המשתמשים כתב — ״קליק אחד למעלה ואני מקבל את אותו סרט רק לא חוקי, אני לא מבין את הפואנטה, למה אני צריך לשלם בעוד אחרים יכולים לקבל תוכן גנוב?? זה לא פייר??״. נטפליקס הגיבו שהם מודעים לבעיה ולכן הוסיפו את המילה Certified בשם של הטורנטבנוסף - עד שימצא פתרון הם עוברים למודל מצפוני, שבו אנשים משלמים out of good will.לא צריך שרתים - Serverless עד הסוף, וחוסכים בעלויותהCFO הודיע לבורד — אל תזלזלו בטוב לב של אנשים. יש המון אנשים טובים בעולם.נאמר אף פעם ע”י אף CFO? הנה . . .בסופו של דבר זו פשוט הכרה אמיצה במציאותיש מלא מפתחים לגייס? אפשר להתחיל משהו . . .גוגל עוברת לירוק ובריא - גוגל הכריזה בכנס בריאות ותזונה בינ״ל שהיא תפסיק לקרוא לשמות של אנדרויד לפי סולם א״ב ממתקים — כלומר סולם שבו היא מתחילה באות A ועולה בא״ב האנגלי כאשר בעבר הקפידה לבחור שמות של ממתקים —  והיא עוברת לפירות וירקות, כדי לייצר וויב מוקדם לשינוי בריא, מתחילים מהתחלה.כבר יש לנו את השם של האנדרואיד הבא: Android Appleד”ש לטים אפלואחד אחרון - מונגו ידידינו מאבד המידע: חוקרים גילו שהוא אכן מאבד מידע, ועכשיו מדווחים על כלי AI שיודע לאבחן אובדן מידע מ-MongoDB ולשחזר אותוהחברה הודתה שהכלי עובד - והכריזה שאפשר לקבל החזר! לקיחת אחריות מבורכת.האם אפשר לשלב את המנוע בתוך MongoDB, ואז להפסיק לאבד מידע? יש מצב שהם עובדים על זההאיבוד והשחזור צריכים להיות מאוד מהירים בשביל זה (Eventual consistency זה לא, אבל גם משהו)לכל מי ששרד עד כאן - התאריך הוא 1 באפריל 2019, וכל הנאמר הינו המצאה פראית.שוב - נכון להקלטת הפרק. למציאות יש נטייה להתאים את עצמה לפעמים . . . פרקי 1 באפריל קודמים - 38, 47 . . . - המצאת שפות תכנות, תוכניות הגירה לבכירים בעולם התוכנה, Frameworks חדשניים ופיקטיבים לזמנם, וחלק פשוט הקדימו אותו.וכמובן שיש כנס! זה לא 1 באפריל  הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

Users want to see their data fast, immediately, now. Whether you’re working with an ORM or writing native SQL, you probably had a “scratching-my-head-trying-to-figure-out-why-this-query-is-so-slow” moment. The team at EverSQL analysed more than 30,000 SQL queries from thousands of different companies, to lay down the most common mistakes developers do when writing SQL queries. This talk will focus on writing SQL the right way, the fast way.MP3

When was the last time you wrote an algorithm to plan your diet? As programmers we do amazing things in our everyday job, but rarely do we use our knowledge at home. In this talk I will introduce genetic algorithms and share how I coded a genetic algorithm from scratch and used it to generate my weekly schedule and to create a smart diet planer. We will go through the different stages of the algorithm and understand how they affect the algorithm’s solutions. Let me show you a different side of genetic algorithms and you will discover a new way to solve your everyday problems.MP3

פודקאסט מספר 363 של רברס עם פלטפורמה - אורי ורן מארחים את יקי ויובל מחברת NVIDIA לשיחה (קצת) על החברה בישראל ו(בעיקר) על מה עושים היום עם GPU, האפליקציות המעניינות ומהם הדברים עליהם עובדים בישראל.יקי טבקה מוגדר ב-NVIDIA כ- Distinguished Engineer (כמו Individual Contributor, ברמה גבוהה), עוסק כבר הרבה שנים בכלי פיתוח תוכנה, בעיקר בתחום של גרפיקה תלת-מימדית, חישוב מקבילי ובינה מלאכותית.יובל מזור הוא Senior Solution Architect ב-NVIDIA - זה שתפקידו לקחת את הטכנולוגיות שיקי מדבר עליהן (וגם בונה, וגם עובדים יחד) וליישם אצל לקוחות.אם יצא לכם לפרק מחשב פעם ולראות מה יש בפנים, בטח נתקלתם בלוגו ירוק יפה של NVIDIA - החברה מוכרת הסטורית בהקשר של כרטיסים גראפיים, והיום (וכבר לא מעט זמן) יש כבר הרבה יותר מזה.החברה נוסדה ב-1993 ע”י שלושה יזמים עם ~$20M השקעה של VC, היום החברה מוערכת בכ-$90B, ויש לה מעל 11,000 עובדים. גדלה יפה.ההתחלה הייתה עם כרטיסי משחק - המעבד המרכזי לא ממש מתאים לציור פיקסלים, והתחילו לייצר מאיצים למיניהם. הראשון ש-NVIDIA הוציאה ב-98 נקרא RIVA TNT, שידע לייצר 2 פיקסלים במקביל (!).מאז התחום התחום התפתח . . .  הכרטיס הנוכחי יודע לעשות Ray Tracing, בינה מלאכותית, לשמש כמובן ככרטיס ל-Gaming - ומגיע מבחינת ביצועים ל-14 טרה-פלופס (Tera FLOPS), שזה מספר לא ממש נתפס עם 12 אפסים של פעולות בשנייה.החברה פעולת בשלושה שווקים מרכזיים - גרפיקה תלת מימדית:  Gaming, Professional Graphics (CAD, CAM, MRI, etc.) and moreחישוב מקבילי (High Performance Computing, Super Computers) בינה מלאכותית - בעיקר Deep Neural Networksבערך בשנת 2001, כרטיסים גרפיים החלו להיות ניתנים לתכנות (לפני כן היו Fixed pipeline), מה שגרם לאנשים לחשוב “למה רק גרפיקה?” - אפשר גם פיסיקה, חישוב מזג אוויר ועוד - ונוצר התחום של General Purpose computing on GPUs :GPGPU, שהפך למאוד משמעותי ב-NVIDIA.127 מתוך 500 מחשבי העל הגדולים בעולם כוללים מעבדים של NVIDIA, מערכים של High Performance Computing ועוד.רגע, GPU ו-CPU . . . על ה-Central Processing Unit אפשר להריץ חישובים (גם פיסיקליים) למיניהם, אז למה ה-GPU (או ה-GPGPU) יודע יותר טוב?אלו שני יצורים שונים לגמרי, עם מטרות שונותהמטרה של ה-CPU היא לקחת כל Thread ולהריץ אותו הכי מהר שאפשר (Minimal Latency). יש המון “טריקים” לאיך אפשר עשות את זה: למשל Out Of Order Execution  - אם צריך לחשב ++i וגם ++j אז אפשר במקביל; אפשר לעשות Pre-fetching (למשל להביא נתון מהזכרון לשימוש בעוד 20 פקודות כדי שלא יחכה, אם אני יודע לצפות את זה סטטיסטית), אפשר לעשות Branch Prediction ועוד הרבה שיטות.זה מתאים להמון אפליקציות - Office למשל, או בכלל כל אפליקציה עם לוגיקה סדרתית. “סדרתית” זו מילת המפתח, כי לפעמים אנחנו מגיעים לבעיות שהן “Embarrassingly Parallel” - ניתנות לפירוק להמון בעיות “קטנות” ומקביליות, למשל גרפיקה תלת-מימדית, חישובי מטארולוגיה וכו’. לזה כבר מתאים יותר GPU.ה-GPU הוא מכונה שנועדה למקסימום Throughput (בשונה ממינמום Latency של ה CPU)איך זה עובד? לדוגמא אותו מעבד גרפי למשחקים שדיברנו עליו (ההוא עם ה- 14TeraFLOPS. . .) יודע “להחזיק באוויר” 4600 Warps - כש-Warp מייצג 32 יחידות אריתמטיות לוגיות (ALU) שיודעות לעשות כפל, חילוק וכו’. בניגוד ל-Thread של ה-CPU שמחזיק Instruction Pointer לכל ALU, כאן יש 32 יחידות לוגיות עם Instruction Pointer יחיד שיודע לעשות Crunching לכל ה-32 פעולות במקביל.תנשמו עמוק - יש 4600 כאלה במקביל.נזכיר שהמטרה היא אופטימיזציה של Throughput ולא Latency, אז אם  למשל נתקעים כי צריך נתון מהזכרון, פשוט “זורקים הצידה” את ה Warp שרץ ומריצים Warp אחר. אם גם הוא ניתקע - שוב זורקים ומריצים עוד אחד - וכיוון שיש כמות עצומה של כאלה באוויר, אנחנו “מחביאים” את ה-Latency שלהם - כל אחד לא בהכרח רץ הכי מהר שהוא יכול, אבל ה-Throughput הוא עצום.רן רוצה להקשות בכל זאת - בשנים האחרונות (יותר מ-10 כבר) יש מעבדים מרובי ליבות (32, 64, איפה עצרנו?). האם זה נותן פתרון דומה ל-GPU?לא.טכנית - אפילו מבחינה מספרית, מעבד עם 8 ליבות ונניח 16 Threads או אפילו 32 או 64 - כשה-GPU יודע לבצע סדר 150,000 פעולות ALU במקביל . . . זה בסדר גודל שונה לחלוטין. אולי אם היה לי מעבד עם 150,000 ליבות היה על מה לדבר.האם יש גם שוני ב-  instruction set? יש דברים שפשוט יותר קל לעשות ב-GPU, מעבר ל-Throughput?כן - ה - Instruction set שונה חלוטין. ומכאן צוללים (נשימה עמוקה) - דוגמא למה שיש ב-GPU ואין ב-CPU: נניח שהגענו לתנאי כלשהו (if statement, branch condition), וה-Warp מורכב מ-32 ALU, כש-16 “הולכים שמאלה” ו-16 “ימינה” - מה עכשיו? יש Instruction point יחיד לכל 32 ה ALUs וזו בעיה. בכדי לפתור אותה, צריך קודם להריץ צד אחד ואחרי כן צד שני. במקרה כזה יש לי Register שאומר אילו Warps פעילים בכל שלב של ה - Execution - זה נקרא Predicate Register. חוץ מזה יש הבדלים ברמת שפת המכונה, והבדלים עצומים במבנה הזכרון - ב-GPU אני יודע ש-32 Threads  ייגשו במקביל למידע, אז ההתייחסות הלוקאלית שונה לחלוטין מזו של CPU.יש המון רכיבים שנועדו במקור לגרפיקה, כמו למשל Texture units שנועדו לאפשר פילטרים על טקסטורות בזמן הגישה למידע או Hierarchical Z-Buffer שמאפשר “לזרוק” הרבה פיקסלים שאין בהם צורך.וזה ממשיך - יש Video Encoding ו- Video Transcoding, שיש היום (כבר לא מעט שנים) גם על CPUיש רכיבים של בינה מלאכותית על ה-GPU, שיודעים להריץ half (16–bit) float, במהירות די מטורפת . . .בסופו של דבר, אפשר להסתכל על ה-GPU כ Dedicated Hardware, ייעודי לכמה משימות הספציפיות (גרפיקה תלת מימדית, חישוב מקבילי, בינה מלאכותית וכ”ד) עם המון רכיבי חומרה שמיועדים לפתור צווארי בקבוק ספציפיים למשימות הללו.דיברנו על זה שבהתחלה GPU נועדו לגרפיקה, היום הטרנדים החמים הם בינה מלאכותית (AI), למידת מכונה (ML) או הבאז הנוכחי בזמן שאתם קוראים / מאזינים. אפשר להניח שהסיבה להצלחה היא שבעולם הבעיות הזה אפשר לחלק להמון בעיות קטנות ולבצע את החישוב באופן מקבילי.האם ניתן לבצע את אותו החישוב גם על CPU (וה-GPU “פשוט” יותר מהיר”), או שאלו עולמות שונים לחלוטין ובכלל לא ניתן לבצע את החישוב על CPU?אפשר להריץ בינה מלאכותית על CPU, זה ירוץ יותר לאט (בכמה סדרי גודל), יצרוך יותר חשמל, והתשובה תתקבל אחרי (נגיד) שבוע במקום כמה שעות.קצת יותר לעומק (כן, יש הרבה) - בעיות של בינה מלאכותית ניתנות במידה רבה לתיאור באופן מתימטי ככפל מטריצות (כי כל הכיף ממערכות ספרתיות עשה חשק לקצת אלגברה לינארית, לא?). כפל מטריצות זו בעיה שהיא “Embarrassingly Parallel”.כשאנחנו מדברים על 150,000 ליבות ומטריצות שהן מאוד גדולות, כשהמטרה היא מקסימום Throughput ולאו דווקא מינימום Latency, ניתן להגיע למצבים בהם GPU מאיץ פתרון בעיית AI או ML בסדרי גודל של x10 או x15.מתי התחלנו לראות את השימוש הנפוץ יותר GPU בתחום של AI?“המפץ הגדול” של AI התרחש ב-2011בעולמות ה-Computer Vision יש תחרות שנקראת ImageNet, שבה מציגים למערכת לומדת 1.5 מיליון תמונות, מבקשים ממנה ללמוד מאפיינים - ואז לזהות כמה מאות אלפי תמונות לא מתוייגות.מה שקרה ב-2011 היה חוקר מאוניברסיטת טורונטו בשם אלכס קריצ’בסקי (Alex Krizhevsky) - שבפעם הראשונה השתמש בטכניקה של רשת נוירונים (ארכיטקטורה בשם Convolutional Neural Networks).עד לתחרות הזו, בכל שנה הגיעו לתחרות מומחי עיבוד תמונה (Image Processing), שהיו צריכים לכתוב “ידנית” תהליכים לזיהוי של מאפיינים. הפעם אלכס הגיע, השתמש בשני GPU של NVIDIA (אותם GPGPU שבדר”כ משמשים לגרפיקה), כתב באמצעות Cuda (שפה מקבילית עבור GPUs), אימן את הרשתות במשך שבועיים-שלושה - ושיפר את התוצאות ב-ImageNet ב 12-13% . . . עד אז דובר כל שנה על שיפור בסדר גודל של עשיריות האחוז. מה שיוסיין בולט עשה לשיא בריצת 100 מ’? כזה.אותה עבודה של אלכס קריצ’בסקי הפכה למה שאנחנו היום מכנים Deep Learningעל שמו נקרא אחד המודלים הראשונים של Computer Vision - כן, AlexNet . . .סיכום ביניים - עד אז חוקרים של ראייה ממוחשבת (Computer Vision) שהיו מעוניינים לזהות (למשל) פרצוף, היו צריכים להחליט על סט של מאפיינים (מרחק בין העיניים, זוית בין העין לאף, וכו’) יחסית פשוטים שניתן להפיק מהתמונה באמצעות פונקציות טריגונומטריות יחסית פשוטות - ולזהות באופן “ידני”. הכיוון הזה הראה שיפור אינקרמנטלי של שברירי אחוזים בשנה. כל זה -  עד שהגיע אלכס קריצ’בסקי ואמר (בערך): אני לא יודע כלום על התמונות מראש, אבל אני יכול לאמן מחשב במשך שבועיים והוא יגיד לי מה הם הפיצ’רים המשמעותיים, ואיתם (ועם מספיק זמן ומידע) הוא יבנה מסווג לתמונות שיהיה בסדר גודל יותר מדוייק מהשיטות הקיימות.כנ”ל לגבי הפרדה בין כלב לחתול, בין משאית לכלי רכב אחר, בין מיג ל-F16 - וזה הבסיס ל-Deep Learning.מוסיפים עוד ועוד שכבות - וה-GPU משמש בתפקיד משמעותי של מאיץ - מאוד יעיל עבור חזרה אריתמטית על אותן פעולות שוב ושוב, וחזרה על הדאטה עשרות ומאות אלפי פעמים (מראים מליוני תמונות וכל אחת אלפי פעמים)ההתעסקות ברשתות נוירונים היא “עתיקה” יחסית - מתועדת כבר סביב 1965.מה שפרץ את הדרך היה השימוש ב-GPU שאפשר לבצע את החזרתיות הזו בהיקפים אדירים.רן זוכר את האיזכור של רשתות נוירונים בזמן הלימודים בטכניון כמשהו נחמד שאף אחד עדיין לא מצא משהו אפקטיבי לעשות איתו. ובכן, קרו מאז כמה דברים . . .התקופה הזו מכונה היום כ- AI Winter (לא כזה) - “זה מעניין אבל אין מה לעשות אם זה”.ראייה ממוחשבת תמיד הצריכה Feature Engineering מאוד מורכב, ולקח זמן להצליח לעשות את זה ב-Scale.העולמות בהם Deep Learning עובד טוב הם כאלה שיש בהם המון מידע ודורשים יכולת קוגניטיביתבשביל לקחת Excel ולמצוא קשר בין עמודות, Machine Learning “קלאסי” יעשה עבודה טובה; בשביל להחליט האם מדובר בחתול או האם זהו אותו חתול רק בזווית אחרת - זה משהו שלאדם אולי יהיה קל לעשות, אבל היכולת שלנו לתאר את התהליך באמצעות סט של חוקים (If A then B) מוגבלת (עד כדי לא קיימת), וכאן מגיעות רשתות נוירונים וארכיטקטורות Deep Learning לעזרה.דאגלס אדאמס (שוב) צדק - התשובה זה החלק הקל, העניין הוא שאנחנו לא יודעים מה השאלה.מאז 2011 ו AlexNet התרחשו הרבה דברים, החורף נגמר - איפה אנחנו היום? מה מעניין (מעבר לזיהוי תמונות של חתולים)?איפה להתחיל? . . .ישראל נחשבת ב-NVIDIA כאחת מחמש “מעצמות ה-AI” העולמיות, באותה קטיגוריה עם ארה”ב, סין, קנדה ובריטניה.מה בארץ? כל נושא ניתוח הדמיות רפואיות (Medical Images) - ברדיולוגיה למשל, עד שרדיולוג מומחה רואה תמונה של מטופל יכולים לעבור כמה שבועות, ויש חברה ישראלית שיודעת לקחת את התמונות ולהגיד האם יש משהו באמת חריג ולהפנות לרדיולוג מיד.כן - Zebra Medical (גם כאן)באופן די דומה יש בישראל חברות שיודעות לזהות מזיקים על צמחים - {meshek{76, טאראניסיש גם עיבוד שפה - Text-to-Speech ו-Speech-to-Text - בשנתיים האחרונות רואים שיפור משמעותי בטיפול בטקסטים ארוכים (כולל לופ שהזכרנו שגורם לגוגל לשבור את ה-Capcha של עצמה), כשהסיבה היא שגוגל עברו למה שמכונה Neural Machine Translation - במקום מערכת סטטיסטית עברו להתבסס על רשתות נוירונים.וכמובן - המון עבודה בתחום הבטחוני: זיהוי עצמים מתצלומי אוויר, ניתוח אותות שיכולים לשמש לאיתור מנהרות (ממש Deep Learning), טיסנים ועוד.ומה ש-NVIDIA עוסקת בו המון: רכב אוטונומי (דוגמא ישראלית - Cognata). לדעת בדיוק מה קורה על הכביש - האם זהו הולך רגל או עצם סטטי? איך עוברים נתיב? איפה אני נמצא בעולם?קיימות, סדר גודל, של 20 רשתות נוירונים שונות בתוך רכב אוטונומי שצריכות לדבר אחת עם השנייה, לנתח את מיקום הרכב בעולם ולהחליט על השלב הבא.הרוב המכריע מגיע מניתוח תמונות - במובן הרחב: תמונות ראדאר, LADAR, אינפרא-אדום ועוד מגוון סיגנלים וערוצים שונים.כל זאת - בניגוד לקבלת החלטות (“לפנות ימינה?”), שהיום לא נעשית באמצעות Deep Learning?דווקא כן . . . Sensor Fusion - לקחת את כל המידע, כולל הפעולות של הנהג, מפות עם רזולוציה גבוהה וכו’ - ולקבל החלטה (בשילוב תנאי מזג אוויר, מצב התנועה ועוד).ושוב - דוגמא למשהו קוגניטיבי, שנהג אנושי עושה כביכול “בלי לחשוב”.אפשר לצלול גם כאן (וכמובן שלא נפספס את ההזדמנות) -  איך בכלל אוספים מידע עבור רכב אוטונומי?הסטטיסטיקה מדברת על סדר גודל 700 הרוגים לכל מיליון ק”מ של נסיעה (?)צריך “לנסוע” סדר גודל של 11 מיליארד מייל (17.7 מליון ק”מ) כדי שרכב אוטונומי יוגדר כ”בטוח”. יהיה קצת קשה לנסוע את זה פיסית (יש מצב שזה מה שאילון מאסק ניסה?), אז ב-NVIDIA מנסים באמצעות סימולציות וגרפיקה של עולמות וירטואליים ליצור סימולציה של כל מיני סיטואציות - מזג אוויר, שמש בעיניים בזויות מסויימות, נהג “שנדחף”, מגדל מים שקורס באמצע הכביש ועוד ועוד . . . הרכב מקבל את כל ה-Input הוירטואלי הזה ואמור להגיב (או ללמוד להגיב) בעולם וירטואלי.כל רכב שיוצא מהמפעל נדרש לאימון של 17 מיליארד ק”מ?לא צריך כל אחד בנפרד, אלא שהמחשב שנמצא בתוך הרכב יהיה עם הידע הנרכש בעקבות נהיגה של 17 מיליארד ק”מ. את מודל הידע הזה אני יכול להשתיל בהרבה רכבים (עם אותם מאפיינים - אותו אוסף של מטריצות). Matrix . . .זה עובד גם עם בני נוער בתקופת הליווי אחרי מעבר טסט נהיגה?! לא, אבל ברכב זה עובד - משנים את רשת הנוירונים במוח כך שתייצג את הידע הנרכש.עוד יתרון של רשת נוירונים - נניח שרכב אוטונומי (חס ושלום) דרס מישהו (נניח רובוט אחר), אפשר ללמד את הרשת את מקרה הזה, ולהטעין את כל הרשת בידע החדש לכל הרכבים שמשתמשים ברשת הזו. במקום Recall - שולחים Over the air updates.אפשר ללמוד נהיגה בלי לעלות על הכביש - רק שאם כל הרכבים אוטונומיים אז לא צריך ללמוד נהיגה . . .האם מדובר במסכים ומצלמות על הרכב שקולטות את המידע, או משהו וירטואלי?מבחינה טכנית זו גישה שנקראת Hardware in the Loop - שני מחשבים (מחשבי על) “שמדברים” אחד עם השני - אחד אחראי על יצירה של העולם הוירטואלי (מזג אוויר וכו’), ומזין אל השני - עליו נמצאת התוכנה. מקור המידע (LADAR, מצלמות, אינפרא אדום או משהו אחר) פחות משנה כי זה הכל “זרם של מספרים”.המדיום בינארי ולא אנאלוגי - זה הכל ביטים . . .ואם אנחנו כבר כאן - אפשר להריץ אלפי מחשבים (כי מזמן לא דיברנו על עננים ו-Serverless) בקצבים הרבה יותר מהירים ממה שבני אדם מסוגלים לעשות (סימולציה של אלפי שניות בשנייה “מציאותית” אחת), וכך אנחנו יכולים לאסוף ולייצר את אותם 11 מיליארד מיילים.“אנחנו” זה NVIDIA או הלקוחות? גם וגם. NVIDIA יכולה לספק, מעבר למחשב העל שיושב ברכב (בהספקים של 300-400 וואט) גם חלק מהרשתות האלה. יש יצרנים שמעדיפים לפתח את זה לבד.עבור רמות 4 ו-5 של רכב אוטונומי (רמת ה”לסמוך על הרכב שיקח את הילד לגן”) צריך הכל כפול - כפילות של רכיבי חומרה, מימושים שונים של כל אלגוריתם וכו’, ואז גם אם אתה יצרן של רכב אוטונומי ומפתח אלגוריתם משלך, NVIDIA יכולה לספק את הגיבוי.איך אלגוריתם אחד מחליט שהשני טעה? מעניין . . .מה לגבי אפליצקיה אחרת של GPU - מסדי נתונים?יש היום Databases שרצים על GPU שמצליחים להאיץ מאוד כל עיבוד המידע עליהםמי אמר SQream? וזו רק דוגמא אחתעל הנייר זה נשמע כמו כלי אידיאלי להרצת שאילתות על מסדי נתונים - הרבה מידע וחיתוכים, נשמע כמו משהו שתפור על GPU, רק ש . . .תחום ה-Databases בעולם מסורתית מאוד שמרני - כלל האצבע מדבר על “לא לגעת ב-Database לפני שהוא עבר עשר שנים בשוק”.ביצועי ה-GPU בשוק מאוד מרשימים - אבל השוק באופן כללי עדיין ממתין לוודא שהעסק יציביש מימושים - אבל כיום עדיין בעיקר לא עבור אפליקציות שהן Mission Critical - דברים שאפשר לעשות Offline בצורה מהירה.  כן יש ציפייה שזה יכנס יותר ויותר.בהרבה מקרים צווארי הבקבוק במסדי נתונים נובעים מקצבי I/O ולא יכולת חישוב (I/O-bound ולא Compute-bound) - ה-GPU יכול לעזור יותר ב-Compute?כן, אם כי בהרבה מסדי נתונים הנתונים בעמודות (אותו סוג מידע) מוחזקים כשהם מכווצים (Compressed) - באופן של-GPU מאוד קל לפתוח אותה (על הדיסק), ובכך פותרים את בעיות ה-I/O: טוענים את המידע מכווץ (compressed) ל-GPU, והוא נפתח שם “בלי עלות” (בגלל כוח החישוב העצום יחסית שזמין).אז מה קורה כיום ב-NVIDIA - בונים GPU נפרד למסדי נתונים, ואחד אחר למכוניות אוטונומיות וכו’?במהות - הליבות (Core) הפנימיות מאוד דומות, ויש Stream Multiprocessor שהוא הבסיס של הGPUאותו SM יכול לבוא במגוןן של מינונים, בהתאם לצורך - יש מקומות שהחישוביות (Compute) קריטית, יש יישומים לגרפיקה, יש מקרים בהם צריך יותר Texture memory וכו’ - וכך יש כמה קווי מוצרים.למשל - קו מוצרים לגרפיקה שנקרא GeForce, קו מוצרים ל-Professional Gaming שקרא QUADRO, יש קו מוצרים לשרתים ול-AI שנקרא TESLA - בכל אחד מהם הרכיבים במינונים קצת שונים, לדוגמא - יכולות DMA, כמות ה SMים, רכיבים ייעודיים לשרתים וכו’.אנחנו בעיקר מדברים על אופטיזציות, ועדיין ניתן להריץ כל אפליקציה על כל סוג?כן - למשל ב-TESLA, אנחנו כיום בדור שנקרא Turing, והחל מדור שנקרא Volta יש למשל ליבות מיוחדות לטיפול בהכפלת מטריצות, ואז  אפשר לעבוד ב- 16bit ל-PF, ולא 32, מה שמוביל להאצה מאוד משמעותיתפעם שנייה שאנחנו נוגעים בהבדל שבין 16bit לעומת 32bit - למה זה חשוב, בזמן שרוב האפליקציות הן ל-32?הרבה פעמים, לפחות בהקשר של רשתות נוירונים, מספיק לשמור את המידע ב - 16bit, ואפשר פשוט לחסוך (זכרון, יכולת חישוב).הצד השני - (HPC (High Performance Computing, שם מדברים על 64bit למשל עבור סמולציות של מזג אוויר או תנועה של מולקולות וכו’ - ואי אפשר לוותר על כלום.חשוב לשים לב שהירידה מ-32 ל-16Bit מאוד משמעותית - לדוגמא, בכרטיסים האחרונים של NVIDIA אפשר לבצע 16 Tera-FLOPS עם 32 bit floating, כאשר אם יורדים ל- 16 bit floating מגיעים לאיזור ה- 110 Tera-FLOPS, וזה כבר סדר גודל שונה לחלוטין.צריך לקחת בחשבון גם שלא כל היישומים של רשתות נוירונים (neural networks) הם זהים - אפשר לאמן רשת נוירונים, ואז אנחנו רוצים לעבוד ב-32 או 16 bit, ואחר כך כאשר המודל מוכן ורוצים לייצר חיזוי מעל מידע חדש, אולי נרצה לעבוד עם אפילו עם 8 bit (ל-Integer), ובאופן הזה לקבל ביצועים הרבה יותר גבוהים.עם Turing, יש אפילו תמיכה ב-4 bit.אם מסתכלים שנה (או אפילו חמש שנים) קדימה - עם אילו אתגרים יהיה צריך להתמודד בתחום של ה-GPU? משהו יותר מהותי מ”יותר גדול, יותר מהר, יותר X” - באילו אפליקציות לא משתמשים כיום ב-GPU וניתן להביא ערך?יש המון כאלה - התחום רק הולך וגדל, והשוק שיכול להפיק ערך מבינה מלאכותית הולך וגדל בשנים האחרונות - זה כיוון אחד (השוק שגדל).מהצד השני, אפשר להסתכל על התחומים “המסורתיים” של NVIDIA.בגרפיקה תלת מימדית - משחקים “צויירו” עד היום בטכנולוגיה שנקראית Raster, שבה מתבצע חישוב תאורה עבור כל משולש בנפרד. מצד אחד זה מאפשר מקביליות מאוד גבוהה, אבל מצד שני - זה עולה באיכות (כשרוצים לעבוד על כמה משולשים למשל - השתקפיות, צללים וכו’). הכרטיס האחרון של NVIDIA עשה צעד ראשון לכיוון Ray Tracing - סימולציה פיסיקלית של קרני האור, מה שמאפשר איכויות מאוד גבוהות של תמונה (עד כדי חוסר יכולות להבחין בין תמונה סינטטית לתמונה “אמיתית” בסרטים של Pixar למשל (כאן יש תיאור של האתגרים). במשחקי מחשב אנחנו עוד לא שם אבל זה בהחלט הכיוון.יש פרק של עושים היסטוריה עם רן לוי על עמק המוזרות, שבין השאר מדבר על כך שככל שאתה מנסה להיות יותר אמיתי עם דמות, כך היא גורמת ליותר אי-נוחות לצופה: אם ברור שזו דמות מצויירת (מיקי מאוס) אז בני אדם מרגישים בסדר עם זה, אבל אם הדמות כמעט-אנושית אבל קצת רובוטית מדי זה כבר הופך קריפי (ד”ש לארנולד שוורצנגר).יכול להיות שנעבור את עמק המוזרות, וכבר בכלל לא נבחין בהבדל - ל-NVIDIA כבר היום יש מוצרים שמסוגלים לג’נרט (to generate) פנים “אמיתיות”, הארכיטרקטורה נקראית GAN - Generative Adversary Networks.המוח אנושי יודע להבחין היטב בפרצופים אנושיים (עם איברים אחרים זה פחות בולט), ולכן זה אתגר מאוד מסובך. יש היום שיטות שמדמות שכבות שונות של עור עם הדמייה של מעבר אור דרכן באופן לא שווה, עם השתקפויות ועוד - על מנת לייצר תמונה שנתפסת כאמיתית.ולמשהו קצת אחר - מהו GTC 2019?ובכן - GPU Technology Conference . . . זהו הכנס המרכזי של NVIDIAהכנס השנה יתקיים בסאן חוזה, 17-21 במרץ - וכל מי שעוסק ב-GPU, בינה מלאכותית, גרפיקה תלת-מימדית וכו’ מוזמן. טובי המרצים מגיעים, כמות הגשת ההצעות להרצאות הייתה הייתה השנה מטורפת.הכנס בדר”כ כולל הכרזות מאוד מעניינות של NVIDIA - אי אפשר עדיין לחשוף בדיוק מה, אבל יהיה מעניין.כמעט כל ההרצאות, גם השנה וגם משנים קודמות (כולל מהכנס שהתקיים בארץ באוקטובר), זמינות לצפייה מאוחר יותר - GTC On-Demand.אז מה עוד לקראת סיום?נושא שחוזר על עצמו לא מעט - יש הרבה פחד ואי ודאות מהתחום של בינה מלאכותית (Hi Elon), ו-NVIDIA לעיתים מקבלת השוואות ל- Cyberdyne Systems . . .בינה מלאכותית לכשלעצמה אינה טובה או רעה - הכל שאלה של איך בוחרים להשתמש בה (Hi John). ככל שנמצא יותר שימושים לבינה מלאכותית כך נמצא יותר מקומות בהם אנחנו לא באמת יכולים להחליף אדם.גם על זה היה פרק מעניין של רן לוי . . . המסקנה הייתה דומהמה לגבי מרכז הפיתוח בישראל - איפה? מה מחפשים?יושבים בגני התערוכה בתל אביב, ביתן 2.יש צוותים שעושים אופטימיזציה ל-Cuda ותשתיות לבינה מלאכותית; יש צוותים שמפתחים כלי פיתוח תוכנה ל GPUs; יש כאלה שעובדים מול לקוחות, ואפילו יש לנו צוות שעושה Research. כ - 30-35 איש בסה”כ.לגמרי מספיק בשביל חסות לכנס רברסים 2019 ;-)הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

פודקאסט מספר 362 של רברס עם פלטפורמה - אורי ורן מארחים את אורי כהן, ידיד הקהילה כבר זמן רב, כיום עובד ב-Elastic (יש מצב ששמעתם את השם איפשהו). השיחה מכוונת לחברה עצמה ומה היא עושה - וגם על איך היא עושה את זה: “חברה מבוזרת”, כשאורי הוא אחד העובדים הבודדים בחברה שנמצא ביום-יום בישראל.קצת על אורי - אורי עובד ב-Elastic כ-3 שנים, מגיע מרקע של פיתוח תוכנה ולפני כ-10 שנים עבר לצד המוצר (Product).כיום אחראי ב-Elastic על ניהול מוצר של כל מוצרי הענן.אז מה זה Elastic?שמעתם על Elastic Search? פלטפורמת קוד פתוח, שנוסדה במקור כמעיין מנוע חיפוש מבוזר מעל סיפרייה בשם Luceneמאפשרת להכניס מידע בצורת מסמכים (Documents) ולערוך עליו חיפושים, סכימות (Aggregations) וניתוחים שונים.הפרויקט שוחרר לעולם ב-2010 ע”י שי בנון, מייסד החברה, ומאז כמות ה-Use Cases גדלה - בהתחלה Log Analytics, וסביבו נוצרו עוד שניים: LogStash - מעיין מיקוד של המידע לפני שנכנס ל-Elastic Search; ו - Kibana - שכבת UI מעל Elastic Search, שיודעת לעשות ויזואליזציה של הדאטה.עבור לא מעט אנשים, זה גם ה-Stack שמעל ELKמותג ידוע ונפוץ, קצת משחק של אהבה-שנאה בתוך החברה - נפוץ, אבל קצת מגביל את ה-Stack של החברה לכיוון של Logs בלבד.לאורך השנים נוספו עוד דברים, כמו Beats ו-ELKB / BELK - ובסוף זה פשוט נקרא Elastic Stackהרבה דברים מעניינים ולא שגרתיים . . .פרוייקט נפוץ ומוערך בקוד פתוח יזם ישראלי שלקח חברה מאפס עד כדי הצלחה מסחרית מרשימההחברה הנפיקה לפי הערכות שווי של כמה מליארדי דולריםהחברה מבוזרת לחלוטיןמוצר טוב. גם חשוב.כל זה - באותה חברה. תודה לשי על אחלה סיפור לפודקאסט!חברה מבוזרת - איך נראה היום-יום בכזו חברה - לובשים פיג’מה ומתחברים ל-Skype? למה בכלל לקום דווקא בבוקר?מבחינת אורי - לקום בבוקר, לפזר את הילדים במסגרות השונות, אימון - והתחלת יום עבודה סביב 9:30-10:00; רוב הבוקר שקט - עבודה מול ארה”ב; סביב 15:00-16:00 מתחילות פגישות עד סביב 19:00; ההמשך תלוי - יש ערבים פנויים ויש כאלה עם עוד סבב פגישות לילה.נשמע פחות מושלם מהאידיאל המדומיין של רן (למעט יום ראשון . . .)מצד אחד יכולת תיאורטית להיות יותר ידידותי למשפחה, ומצד שני - השעות נראות קצת פחות ידידותיות, רוב הערבים מוקדשים לעבודההבוקר רגוע, ואפשר לאכול צהריים עם הילדים, ומצד שני 2-3 ערבים בשבוע סגורים בהרבה מקרים לעבודה אחרי ארוחת הערב.זה גם תלוי-תפקיד - במקרה של אורי זה מאוד רוחבי, כשהוא אחראי על כל מוצרי ה-Cloud (משפחת ה-Hosted Services של Elastic Cloud, וגרסת ה-Private Cloud של החברה - שני מודלים של הפצה לאותו Code base).עיקר העבודה סביב 15:00-16:00 - איך מפרידים?החברה פתוחה לעבודה מהבית, ולפעמים הילדים נכנסים לישיבות . . . כשצריך סוגרים דלת ולפעמים גם זה לא עוזר. יש Tolerance ברמת החברה.איך מנהלים כזו חברה? או אפילו צוות מוצר?דיברנו בעבר על Automattic, עבר זמן . . . בחברה רגילה זה לא “פשוט עובד”ומדובר בחברה גדולה - מעל 1,200 עובדים, וגדלה מהר.התרבות בחברה מאוד חשובה - החברה נוצרה סביב קוד פתוח, והעבודה מלכתחילה התבססה על מבנה מבוזר - מערכות Ticketing, שימוש ב-GitHub וב-Google Docs כשנכנס.היררכיות התקשורת מאוד ברורות - כשצריך תשובה מיידית אז Slack כשרוצים דיונים משמעותיים עוברים ל-Offline: לפעמים Mailing lists או GitHub Tickets (אפשר לראות את הדיונים).כשהא-סינכרוניות מפסיקה לעבוד, מכנסים פגישה ב-Zoom, ומתעדים את ההחלטה עבור כל מי שלא היה או הצטרף מאוחר יותר לחברה למשל.מהם הטריגרים למעבר מתקשורת א-סינכרונית (שהיא מטבע הדברים בעיקרה טקסטואלית) לסינכרונית (“בוא נעלה על שיחה”)?כשרואים שטיקט נתקע, ולא מתקבלת החלטהכשיודעים מראש שמדובר בנושא עם המון דעות וחבל לבזבז אנרגיה על מייליםוצריך המון שיקול דעת ואמפטיה . . . כשמדברים פנים אל פנים יש טון ושפת גוף והמון דברים שהולכים לאיבוד בטקסט, כמו גם הבדלי תרבות וסגנוןהכלל הראשון  - Assume no malice: לקרוא כל דבר מתוך הנחה שמי שכתב התכוון לטובאם צריך - כל אחד יכול לעצור וליזום שיחה (Zoom).זה ערך בחברה - חלק מה-Source code - לא רשימת “עשה ואל-תעשה” אלא משהו שמבטא את רוח החברהיש גם את “Everyone has an accent” - זה לא רק מבטא אלא גם תרבות ועולם דימויים וכו’.וכמובן “Home Dinner” (חשוב שהעובדים יהיו קשורים למשפחה) ו - “Space Time” (לאפשר לאנשים לעשות דברים פחות מובנים וליזום בעצמם)זה לא משהו שהחברה ניבנתה לפיו, אלא סט ערכים שנוצר בחברה ונאסף על מנת שמצטרפים חדשים יכירו.האם חברה מבוזרת = פחות פגישות ויותר עבודה א-סינכרונית אינדיבידואלית?מובנה בחברה - היום פרושה על פני 39 מדיניות והמון איזורי זמן, עם הגדרות שבוע עבודה שונות, כך שלקבוע פגישה זה לא פשוט.גם לפגישות קבועות יש סבב של Time-Zones, כדי שלא כל פעם יהיה נוח רק לאותו איזוריש גם צד פחות טוב - כמות המידע הא-סינכרוני שצריך לעבד היא גדולה מאוד, ובחברה מעדיפים לטעות לכיוון “עודף-מידע” מאשר “חוסר-מידע”, מה שמגביר את זה עוד יותרבוקר טיפוסי כולל כמה שעות של קריאה של מה שקרה בלילה . . .יש פונקציות שאינן מבוזרות - אופרציה? פיננסים?למעט Sales - לא. יש צוותי מכירות בלונדון, צרפת וכו’ - צמודים ללקוחות בהתאם למיקום. כל השאר לא.יש צוותים יותר מבוזרים מאחרים - ל-Marketing למשל יש מרכז כובד ב-Mountain View, אבל ה-Engineering פרוש על פני כל העולם.צוות ה-Cloud של אורי פרוש על פני 13-14 מדינות, בערך בכל איזור זמן שעולה על הדעתקצת לגבי הצד הפסיכולוגי - כל היום עובדים מהבית (רן ניסה פעם ולא היה קל): פתרון אפשרי הוא לשכור משרד ליד הבית, אבל זה עדיין להיות לבד, ואם יש בעיה אתה מתמודד קודם כל בעצמך; מעבר לזה - חיי חברה: מה אתה יודע על חבריך לעבודה? יש להם כלב? הם אוהבים סקי? זה חסר בכלל?כדי שזה יעבוד טוב חייבים גם קשר פיסי בלתי אמצעי - פעמיים בשנה החברה לוקחת את כל צוות ה-Engineering (מאות אנשים), ומטיסה את כולם למקום אחד בארה”ב או באירופה, לשבוע שלם של road map ודיונים אסטרטגיים אבל גם בילויים וארוחות משותפות ליצרת קשר אישי שנשאר גם כשכל אחד חוזר למקום.וכן - זה חסר.חלק מכוסה, לפחות חלקית, באמצעים אחרים - ערוץ Water Cooler ב-Slack למשל, עבור תקשורת פחות פורמלית, בדיחות וכו’.כל אחד יכול לשכור משרד. אורי ניסה וגילה שבסוף יותר נוח לו בבית, ומתרגלים.בארץ כבר יש 10-11 אנשים ויש ערוץ ישראלי (עובדים בראשון, אפשר לדבר עברית וכו’)אפשר לעבוד יחד, אבל יש לזה השלכות - לדוגמא - בצוות שאורי עובד איתו יש פגישה שבועית, כש-20 מתוך 30 חברי הצוות נמצאים ב-Mountain View. כאשר הפגישה השבועית התקיימה עם 20 איש בחדר אחד ועוד 10 ב-Zoom, מי שהתחבר מרחוק איבד הרבה מהשיחה. ההחלטה הייתה ליצור Level Plain Field —> גם מי שבמשרד מתחבר “מרחוק”, ואז כולם באותם תנאים, אין שיחות צדדיות (יש Slack . . .) וכו’.ועדיין - יש דוגמאות של שני עובדים ששכרו יחד משרד בתל אביב.הפגישות עצמן - הם רק עסקים או גם צחוק? רן מזכיר וידאו של מנכ”ל (?) Trello (עוד חברה מבוזרת, או לפחות הייתה) מלפני שנתיים בערך, שאמר שכל פגישה מתחילה ב-10 דקות של Small Talk, באופן מובנה (הבלוג שלהם עדיין מלא בזה). האם יש משהו כזה ב-Elastic?לא משהו מובנה, אבל מעניין דווקא - כמעט כל פגישה מתחילחה ב 3-5 דקות של Small Talk, ואולי זה משהו שצריך לאמץ.בכל מקרה - פגישות חייבות להיות מובנות (לא רק ב-Zoom): יש פרוטוקול לפגישות, אג’נדה ברורה, מסמך שמוצמד לזימון, מישהו שאחראי לכתוב Notes. מאוד מסודרים עבור פגישות אפקטיביות.טכנולוגית - אין כאן משהו חדש (Google Docs, GitHub, Slack, Zoom . . .). הקסם הוא בתרבות ולא בכלים.לא מזמן החברה הונפקה (אוקטובר 2018) - וזה משהו שיש לו פוטנציאל לאימפקט משמעותי על החברה. ועדיין - אין חדר שבו כולם יכולים להיפגש להרים כוסית . . . אין נראה יום כזה? או היום שאחרי? מה השתנה?היה לאורי המזל והכבוד להיות בניו יורק בזמן ההנפקה, והגישה הייתה מאוד מסודרת - אי אפשר לחשוף את תאריך ההנפקה למי שלא הגיע ספציפית עד שבוע לפניכשחושפים - פותחים Zoom כללי לכולם, הייתה אפילו הקצאת Expense לקנות יין . . .היה שידור ישיר מה-Trading Floor - שעה-שעתיים של תהליך למציאת המחיר למסחר (ב-NYSE), כשבזמן הזה כולם יחד (האנשים בבית קיבלו גם פרשנות עם הוידאו, וכנראה ידעו אפילו יותר . . .)מה השתנה? החברה מאוד פתוחה, ואחד היסודות של זה הוא שקיפות (Transparency). בהרבה חברות ההחלטות מתקבלות במקום אחד ואז מתוקשרות החוצה כמו שהן, ללא תהליך קבלת ההחלטות, ונוצר מצב שבו אנשים בקצוות שלא מבינים למה הוחלט כך ולא אחרתעל מנת להתמודד עם זה, כל תהליך קבלת ההחלטות מתועד באופן מאוד מפורט, אפשר ללכת ולהסתכל על כל שלב, ויש עדכונים שוטפים מכל פונקציה בארגון באופן שבועימכל צוות ב-Engineering נשלח בכל שבוע עדכון: על מה עובדים, מה התחדש, משרות פתוחות (אם מישהו רוצה לעשות שינוי)מכל זה, Head of Engineering שולח עדכון ברמת כל החברה - אלא הפיצ’רים החדשים, אלו דברים שלא עבדו טוב ומה עשינו וכו’כנ”ל HR, Legal, Sales וכו’לפני ההנפקה היה אפשר לחשוף הרבה יותר, בעיקר מכיוון Sales - כמה מכרנו החודש וכו’ אחרי ההנפקה כבר אסור לעשות את זה . . .עדיין מנסים לשמור על שקיפות - אם לא כל צוות אז פונקציות עיקריותמה יצא, מה ה-Road-map, כל מיני KPI וכו’הייתה גדילה משמעותית בכח-אדם - החברה גדלה גם לפני, ופעלה במעיין Mode הנפקה גם קודם - תהלכים וארגונים נבנו בצורה מסויימתהנפקה מאוד מבגרת את החברה - תהליכים שנראים אפילו מעיקים בהתחלה הרבה פחות מעיקים בהמשך והופכים את ההתנהלות ביום-יום לטובה יותראיך מגייסים אנשים - איך מגיעים אליהם? איך עושים ראיונות? חווית המועמד 0-100 . . .יש מגייסים בכמה מדינות (מועסקים ע”י החברה) - אבל לא בהכרח במדינות בהן מגייסיםמפרסמים משרות באתר - יש לחברה שם טוב ויש כמות גדולה של מועמדים אורגניים מתוך האתריש תוכניות רגילות של חבר מביר חבר וכו’, וגם Sourcing (בעיקר דרך LinkedIn).ראיונות - לגמרי Remote, באמצעות Zoom - 5-6 ראיונות (מסינון recruiter ועד ראיון אחרון)תלוי בתפקיד ובבכירות מי מראייןואז מתחילים לעבוד - Zoom כבר התקנתי, מה עכשיו?תתקין Slack . . .מקבלים הרשאות לכל מה שצריך, לכל צוות יש תהליך On Boarding מאוד מסודר עם מסמכים מפורטיםאחרי שמתאפסים, בונים תוכנית ל-90 ימים ועוקבים אחרי יעדיםהאם יש Online university מסוג כלשהו? יש Offline . . . קוראים לזה X-School, ופעם בחודשיים מטיסים את כל המתגייסים החדשים לכמה ימים ב-Mountain View: יומיים כלליים על החברה ועוד יומיים ספציפיים לתפקיד.מאוד מסודר ומוגדר - יש תמונה קבוצתית שבועית (מי שב-Slack שולח תמונה…)יש גם Online עבור המוצרים עצמם - יש Training.גם עבור מכירות, כולל Certificationגם עבור Engineeringתהליכי On-boarding ספצייפם לצוותים מסויימיםניכנס לראש של עובד צעיר בחברה - פעם ראשונה בחברה מבוזרת כזו, וזו פעם ראשונה שלו לבד עם עצמו, נגיד חודשיים בהתחלה. יש כאלה שעבורם זה עשוי להיות יותר קשה (לפתור באג לבד וכו’). הרבה קושי נוסע מזה שאתה לא יודע שלכולם קשה, כי אתה לא רואה אותם . . . האם יש טפוסי עובדים ספציפיים שזה לא מתאים להם? האם היכולת להיות Lone Wolf (כי מי צריך נינג’ות כשיש צ’אק נוריס) היא משהו שמחפשים בתהליך גיוס?לא בהכרח, כי יש המון עבודת צוות - פשוט במדיומים אחריםלכל עובד חדש מצמידים מנטור, בדרך כלל באיזור הזמן של העובד, שעוזר לו להבין מה קורה ולהשלים את תהליך הקליטה בהצלחהועדיין - היו כאלה שבאו אחרי כמה חודשים ואמרו שלא מתאים, אבל זה מיעוט קטן, לפחות במה שאורי חשוף אליוספציפית לטיפוסים - אפשר היה לחשוב שאילו יהיו כאלו שתרמו בעבר לקוד פתוח וכו’, אבל ב-Elastic לא מצאו קורלציה ספציפיתזה אולי שובר בודדים - אבל יש גם כאלה שפורחים. כמו בכל חברה, תמיד יש סיכוי שזה לא יסתדר אבל אין משהו חריגאולי להפך - המספרים של ה-Engagement Survey מאוד גבוהים ביחס לכל מתחרה בקטיגוריה, וגם אבסולוטית. אנשים נהנים . . .אז מה אתם מחפשים - בישראל ובעולם?כמעט הכל . . . עשרות (אם לא מאות) משרות פתוחות באתר, כשכל מה שכתוב עליו Anywhere רלוונטי גם לישראלאין עדיין יישות משפטית בארץ - עובדים בארץ הם עובדי החברה מבחינתה לכל דבר ועניין, אבל טכנית עדיין צריך לעבוד כעצמאי ולהוציא חשבונית לחברה בחו”ל. צפויה להיווצר יישות בארץ, לא ברור בדיוק מתי אבל בקרוב. משהו שצריך לקחת בחשבון.יש בלי סוף משרות Engineering, בכל הצוותים - ב - Elastic Search בעיקר Java ומערכות מבוזרותב - Kibana זה יותר Front-end - JavaScript, Nodeב - Beat - יותר Golang, Scalaיש Marketing, Product, יש בצוות של אורי.כל מה שמסווג כ-Anywhere . . .הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

רן, אלון, ודותן בפרק מספר 56 של באמפרס (361 למניין רברס עם פלטפורמה) - סקירה של טכנלוגיות ודברים מעניינים מהזמן האחרון. רן - בפרק שעבר דיברנו על הרבה הכרזות מה -2018 AWS:reinvent, ונשארו עוד כמה שלא הוזכרו - שירות מנוהל Managed Kafka בשם Amazon MSK - מעניין למי שאוכל Kafka לארוחת בוקר (אנחנו מקבלים את כולם באהבה)יש כבר ל-AWS שירות דומה בשם Kinesis אבל לא בדיוק אותה אופרציהאם אתם בונים מאפס אז אולי זה לא ממש משנה, אבל אם כבר יש משהו שעובד על Kafka אז לעבור זה פחות כיףהקונספט עצמו אולי קצת מאכזב - בשונה מ-Kinesis, זה לא Serverless, צריך לבחור שרת, גודל וכו’; קצת דומה למודל של RDS (ניהול החומרה הוירטואלית נשאר על המשתמש), יוצר בעיות בפיקים (גם ב-Kinesis היה צריך לתכנן Capacity, ועדיין יותר קל לתכנן ל-Scale).עדיין יותר קל מלנהל Kafka בעצמך, לא כל כך זול, לשיקולכם.עצור! עכשיו תמשיך . . . Amazon EC2 מאפשר להשהות (Pause) ואז להמשיך Workloadsאפשר להקפיא Instance בזמן (בלי לעצור אותו), ואז להמשיך מאוחר יותרלא מצאנו שימוש ספציפי עדיין (בכל זאת EC2 as is), אבל רעיון מענייןחלק פחות נחמד - מתרחק מהקונספט של State-less Server (מתחיל מאפס בכל פעם), חוסך את הסקריפט של האתחול ויכול להיות נוח. למה בכל זאת? ממש טוב ל-Chaos Engineering, ולשרתים שומרי שבת. בקרוב ב-B&H?רוצים לתזמן זמני ריצה? AWS Lambda עכשיו תומך ב-Custom Run-times, ומאפשר לשתף קודקודם יכולתם לכתוב באחת מהשפות הנתמכות וזהו, עכשיו אפשר לשתף יותרהמגבלה לגדול הקוד (בשפות Script למיניהן זה כואב יותר) מאפשר לשתף ספריות שכבר “חיות בענן” ואפשר רק לתת רפרנס אליהן בלי כל הקוד.קונספט חדש של Serverless Library? פרקי 1 באפריל ממשיכים להכות . . .עדיין יש את המגבלה של 75Gb לכל הפונקציות Lambda, אבל עכשיו זה פחות אקוטי, כי לא צריך לדפלה (!) את כל הספרייה.כן, “לדפלה” (Deploy) עבר את האקדמיה. או יעבור. מתישהו. אולי. יש פורומים של רופאים שבוחנים תרגום עברית לז’רגון טכני - האם קיים גם לתוכנה? שאילתא לאבשלום קור בדרך.ועוד אחד אחרון - AWS App Mesh: למי שכותב microServices יש צורך ברכיב שעושה את ה-Routing בין השירותים השונים, מוסף Metrics וכו’ - Service Mesh.אחד השירותים הבולטים לזה הוא Envoy, במקור נכתב ב-Lyft והיום כבר קוד פתוח (הזכרנו את Istio שמשתמש ב-Envoy).אז בגדול -  AWS יצרו Envoy מנוהל. חדש, לא השתמשנו עדיין אבל נראה מעניין.עוד מישהו שם לב לכך שבזמן האחרון GitHub מחדשים די הרבה? או פשוט מפרסמים יותר? בכל מקרה - חידושים אחרונים - תוכנית חדשה שמאפשרת Private Repositories בחינם - אם בעבר היה צריך לשלם (או ללכת ל bitbucket או GitLab), נכון להיום אפשר להחזיק מספר Repositories פרטיים עם כמה תורמים Collaborators בכל אחד. אם צריך רק משהו קטן זה סבבה.ועוד אחד - GitHub release Radar: עוברים על הספריות בפרופיל גבוה ועושים סקירה של Releases משמעותיים ומעניינים מהזמן האחרון (חודשי), מפרוייקטים יחסית בוגרים. שווה לעקוב.למשל - Alda: שפת תכנות למוסיקה (!) - מתכנתים ומסיקאים יכולים מאוד להנות מזהנראה כמו קוד, אפשר לבחור כלים ואקורדים, יש מדריך נחמד. מומלץ.מכירים Grafana? מערכת דשבורדים משוכללת, בשימוש בהמון מקומות. התחיל כקוד פתוח והפך לחברה.לפני כמה שבועות הוכרז מוצר חדש - Loki: כמו Prometheus, רק עבור לוגים . . .אפשר לראות שזה מתחרה הELK - אם נוח לכם עם Prometheus, יהיה לכם נוח עם Loki ללוגים.הכל בנוי לפי תויות ולא Full-text - לא מאנדקסים שוב דבר, אבל לכל המטריקות תמצאו גם את הלוגים הרלוונטיים (אם תשתמשו באותן תגיות).נשמע מאוד מעניין ועם הגיון בריא, נקווה שיקיים. אם יודעים מה מחפשים זה אמור לעבוד.חברה-בת של Alphabet (כן, נו - Google) בשם Waymo מריצה כבר כמה חודשים פיילוט לשירות של מכוניות אוטונומיות באריזונה.אמנם יש נהגים אבל רק לגיבוי, הנסיעה אוטונומיתמה שמעניין זה שהתושבים המקומיים מתנכלים למכוניות - חותכים צמיגים, נוסעים בצורה מסוכנת לידן. התפתח אנטי למכוניות, קצת מזכיר את סיפורי הלודיטים מראשית המהפכה התעשייתית.איומים בנשק על הרכב, שוברים חלונות. שמח.בעניין דומה - תאונת סייבר ראשונה, כשרכב אוטונומי של טסלה דרס רובוט . . .אלון - קליל ונחמד - Remove BG: פשוט להעלות תמונה ולהעיף את הרקע שלה…בדמו זה נראה מעולה, במשחק ראשוני קצת פחות, ועדיין לא רע, יש אפילו APIבהמשך לטרנד השירותים לעיבוד תמונה מסוג אחד בלבד (רקע, סטיילינג, וכו’) - ועוד רגע בטח יגיע ה-Editor שמשתמש בכולם בתור שירותים.ספריה בשם TypeORM: זה בעצם ORM עבור Node.jsחביב, וממש מזכיר את ה Active Record של Rubyמזמן לא שמענו על Google ML - הזכרנו שזה לא ממש עבד בפועל, והמאזין דויד ויינברג הפנה את תשומת ליבנו לכך שהם העלו את מספר התמונות הדרוש ל classification מ-100 ל-1000.אנחנו היינו עדים לזה שבהתחלה הם דיברו על 10 . . .קצת עצוב - התוכנית של Ruby 3x3 להיות x3 יותר מהירים תוך 3 שנים? אז ב Ruby 2.6 הוציאו סוף כל סוף Just In Time compiler, רק שאם עובדים עם Rails זה לא רק שלא משפר את הביצועים - זה דופק אותם באופן משמעותי  בטח ב-2020 יורידו את כל השטויות מהקוד ואז זה יהיה באמת x3. לא מחדשים שום דבר לבעלי אייפון.כבר הזכרנו ש-Ruby ,ובכן, קצת מת.אתר בשם The Node.js Security Handbook - מרכז כל מיני עצות ובעיות מוכרות ב Node.jsמי שרוצה לבדוק את עצמו - נחמדועוד אחד - JSX-INFO זה npm שמראה את השימוש של כל האלמנטים שמשתמשים בהם מתוך JSXניתוח נחמד של הקוד. לא ברור עד כמה שימושי, אבל נחמד לסטטיסטיקה.זוכרים את Doom? אז יש כאן הסבר על איך יצרו את האפקט (המהמם) של האש.חוץ מזה, מישהו הוסיף מימוש ב-Javascript עם הסברים.ומי מאחורי Doom? ישוב בהמשךוהיה גם איזה עניין עם Roomba שסורק את החדר ומאפשר לשחק בו Doom אחד החזקים.הרחבה ל-Chrome בשם rxjs-watcher: מאפשר debugging כדי לראות מה קורה תוך כדי ה-Streaming, נחמד.גם GitLab הצטרפו לחגיגת ה-Serverless - מאפשרים להריץ פונקציות בענן שלהם.לא ברור מה היתרון על ספקי ענן אחרים מעבר ל-Ecosystem של GitLab, אבל כולם רוצים היום להריץ פונקציות אז שיהיה.לפעמים רוצים להריץ פעולות כחלק מה-Build - יש למשל גם את GitLab CI, ואם רוצים לגבות DB אן עוד פעולות מהסוג הזה אז יש כאן יתרון מסויים. אז מתי יוצא Reversim Serveless?מתעניינים בלימוד VIM? הנה סדרה של טוויטים עם סרטונים נחמדים ותגובות חיוביותב-Release Radar האחרון של GitHub שהזכרנו קודם דובר על SpaceVim - סביבת עבודה קונסיסטנטית מקונפגת מראש ל-VI (הרעיון הועתק מתוך spaceemacs, על אותו עיקרון) - רן התקין ועד עכשיו נראה די טוב, מאפשר להתקין רק חבילות שצריך (רק Go למשל).ועכשיו להכרזה שדותן חיכה לה כל חייו (?) - MongoDB ב - AWS (!)קוראים לזה DocumentDB, אבל עם תאימות (comparability) ל MongoDB.נשמע כמו משהו מבטיח. לא ניסינו, אבל סומכים על AWS מהניסיון שזה בטח לא מאבד מידע (אולי). ספרו איך היה (אם תזכרו).עוד מהפכה (קטנה) בעולם של React - סופי אלפרט (Sophie Alpert), מי שניהלה את הקבוצה של React, עוזבת את Facebook.לא ברור עדיין איך זה ישפיע, אבל זו דמות משמעותית בעולם של React שעוזבת.ועוד סיפורי כשלונות עם K8S (מעבר לזה שאלון הוקלט אומר “קוברנטיקס” בשידור- בשביל זה תצטרכו ממש להקשיב, זה לא עובר בטקסט)ריכוז של סיפורי נפילות - לא התעמקנו, אבל נראה כמו קריאת לילה נעימה (אם אתם בעניין של סיוטים)דותן - כמה ענייני Rust להסרת חלודה (צריך להתחיל לסגור את הפער מול Go איכשהו, לא?)- סטיב קלבניק (Steve Klabnik) - “הפנים” של התיעוד (Documentation) של Rust - עוזב את Mozilla. האם גם את Rust? תלוי איך קוראים את זה.מוזמנים לחפור ב-Reddit ולקרוא את התגובות ואת הדרמה.כביכול אין מי שיתחזק את התיעוד, מצד שני אולי ייתן לאחרים לצמוח במקום לרכז במקום אחד.אמרנו שנחזור לג’ון קרמק (John Carmack) - האבא של דום ואולי המפתח הכי טוב בעולם - החליט לכתוב ב-Rust (!).רגע - אלון מוסיף ניקוד ללוח בצד של Rustהאיש באופן כללי מנסה הכל והמון, וזה די מדהים בהתחשב ברשימת העיסוקים שלו (כן, גם אתם עסוקים - תהיתם פעם למה התמונת פרופיל שלו כוללת ארמדיל על טיל? האיש הוציא עשרות מיליוני דולרים מהרווחים של Doom על בניית חללית ל-Ansari XPRIZE עם Armadillo Aerospace. פחות עבד בסוף, ועדיין  -יותר עסוק מכם).בפעם האחרונה שהוא ניסה משהו כזה זה היה עם Lisp, ואחרי כמה חודשים הוא הוציא שפה מבוססת-Lisp, שאיתה הוא משתמש ב-Oculus. יש למה לחכות.אה - כן, הוא ה-CTO של Oculus. איש עסוק, אמרנו. ה-CTO המקורי נדרס במסגרת מלחמת כנופיות . . . ג’ון ידידינו החליט להיכנס, ותוך כדי שחרר קטעי וידאו על האתגרים של VR, כולל דגמים שהוא בנה בעצמו בסגנון מקגייוור מדבק וחול בערך. כנראה עומד דרגה אחת לפני משפטי צ’אק נוריס על שמו.מדריך פרקטי להקשחה של לינוקס - מרכז את כל הדברים שאפשר לעשות על מנת להקשיח את הלינוקס שלכם (בהיעדר ניסוח טוב יותר)הקשחה - במובן של הורדת כל האלמנטים והשירותים שאינם בשימוש בפועל, מתוך מחשבה שזה סתם עלול לפתוח איזושהי פירצה אפשרית או לחשוף חולשות שלא לצורךלפעמים דרישות רגולטוריות, לפעמים סתם מתוך פרנואידיותיש שירותים שהם Add-on או אופציונליים מלכתחילה (Audit, Kernel, . . . ) - אם לא משתמשים, שלא יהיה.עוד רשימה ששווה לשמור בצד - Repository בשם Professional Programming - נשמע קצת Fluff, אבל מפתיע עם אחוז גבוה של רלוונטיות, תוכן שכבר לא כל כך זמין ביום-יום אבל הרבה דברים פשוטים ובסיסיים ששווה לשמור (Design Patterns, ארכיטקטורות וכו’).כיסינו פעם כל מיני רטרו 8bit engines - ועכשיו יצא אחד מבוסס React/ Redux ב-Javascript, שהופך את כל העניין ליותר נגישרב המנועים האלה הם שיכפולים של ה-Pico8 - אפשר לערוך סאונד, אנימציה, לכתוב קוד. נחמד שהספציפי הזה מבוסס Javascript.אם מישהו רוצה לשחק בזה עם הילדים, נראה שה-Script8 הוא מקום טוב להתחיל בו.תורת התורים! Queueing theory - למי שלא נתקל איכשהו בלימודים, המון מודלים סטוכסטיים ותיאור יפה של מערכות פיזיות ווירטואליות מבוסס על המון מתימטיקה, ממערכות Kanban ותורים אמיתיים ועד תורים בכל מערכת הנדסית א-סנכרונית (Call Centers וגם חדרי מיון למשל - חפשו מאמרים של פרופ’ אבישי מנדלבאום). כשמכירים את ה-Patterns, יודעים איך לתקוף את הבעיה נכון. וד”ש ל-Erlang C.מעבר חד ל-Front-end - ניסיון לתכנן את 2019 בשתי שאלות:מה המצב? -  State of React -  פוסט שמסכם בצורה טובה, כולל repository עם דוגמאות קוד לכל דבראיך לעשות Typed JavaScript ב-2019? התשובה ה(כמעט) מוחצת היא כנראה TypeScript ולא Flow (נוסטלגיה…), ובתקופה האחרונה צפו המון Pull requests של מעברים ל-TypeScript - כאן יש את Facebook עם Jest שעוברים מ-Flow (מישהו מחליט להשקיע זמן בכזה מעבר)כן, Jest של פייסבוקמי שמכיר את  beautiful dnd של Atlassian - אז גם הםעוד מישהו (David Gomes) שעשה Porting של 30,000 שורות קוד מ-Flow ל-TypeScript - מאמר מצויין למי שמתכנן משהו כזה, עם כלי אוטומציה והרבה פרטיםויש כל מיני דרכים להתחיל - TypeScript-Babel-Starter הוא אחד כזה מבית Microsoftנראה שמתעוררת תנועה לכיוון שימוש ב-TypeScript כאלמנט בתוך האקוסיסטם של Babel ולא כ-Compiler, שווה לעקוב ב-2019, נראה שזה הכיוון.בחזרה ל-State Management - נראה שזו הולכת להיות שנת ה-Redux abstractionsאם לפני שנתיים-שלוש הסתכלנו על ספריות שבאות מעל Redux וחוסכות קוד וזה לא נראה פופלארי במיוחד ואף אחד לא אימץ, אז עכשיו נראה שמשהו משתנה בגישה (ה-hooks הופכים את החיים ליותר פשוטים בסביבה הזו, הזכרנו את Dan Abramov)יש את GraphQL ואת Mobx שיוצרים סביבה יותר נוחה, והקהילה של Redux אולי מרגישה קצת מאחור עם הרבה overhead.מארק אריקסון (Mark Erickson) מנהל רשימת לינקים מטורפת ל-Redux. כבר משהו כמו 3 שנים, כוכב עולה, מעיין Redux Starter Kitהכל נראה כמו Mobx פתאום . . . נחמד לקחת מוצר-כמעט-מדף במקום כל התשתיות הפרטיותעוד ספריה בשם AutoDux של אריק אליוט (Eric Elliot, עוד כוכב עולה) - אותו הדבר בגדולויש גם את mobx state, שהופך קצת פחות אטרקטיבי כי אפשר לקחת דברים יותר “קלים”.והפיל בחדר - GraphQL . . .עוד אייטם - UI Builder עבור Reactמסוג הדברים שתמיד בונים, וכאן יש Open source. לא ברור המודל העסקי (כנראה אין, גם הם לא מצאו ושחררו את הקוד) אבל מגניב.ויש גם SciFi UI לדסקטופ שלכם - מופיע ב-releases של Github שהזכרנו קודםרק להתקין ולהפוך ל-Hacker ויש גם לMac  . . .בא עם קפוצ’ון באופן אוטומטיאחרון - Sampling python profilerכתוב ב-Rust, מהווה Sampling ל-Pythonמתחבר לזיכרון של Python, מייצר Stack Trace, מבין את השימוש . . . עובד טוב שזה די מדהים.פתרון אפשרי אחר - ובן, לעבור ל-Go.ולחלק האמנותי - יש מצב שכבר ראיתם, ועדיין - מה כבר יכול לקרות? Let’s deploy to production . . . 4 דקות של אושר, אל תאכלו קודם כלום, חבל על ניקיון אחר כך.הפנייה מעגלית - הצליחו לעבור את ה-reCapcha של Google עם, ובכן - רכיב זיהוי הקול של Google Cloud . . . רק לבקש את ה-Capcha בסאונד, לשלוח לזיהוי של Google, והוא מזהה ב-85%, שזה יותר טוב מכם.יש גם את הקוד למי שממש רוצה - UnCapchaהאם Google מסוגלים ליצור מערכת שהם לא מסוגלים לשבור?ורגע לפני סיום - כנס רברסים 2019 כבר מתארגן, ה-Call For Papers בעיצומו ופתוח עד סוף פברואר (28.2)למי שעדיין לא הגיש אף פעם - אין דרישות מוקדמות, רק נושא מעניין. תגישו! יש אפילו סדנאות הגשה, וגם סשנים חדשים.הכנס עצמו יערך ביוני בגני התערוכה, מכירת כרטיסים כנראה חודש ומשהו לפני. סמנו ביומנים, יהיה מגניב.הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

רן, אלון, דותן וגם אורי על קולות הרקע בפרק מספר 55 של באמפרס (358 למניין רברס עם פלטפורמה) - סקירה של טכנלוגיות ודברים מעניינים מהזמן האחרון, והפעם - פרק נוסטלגיה חגיגי במיוחד לרגל (חודש ה)עשור לפודקאסט וחמישים (וחמישה) פרקי באמפרס (ההערות בקוד המקור).הכל התחיל לפני לא מעט שנים - Ruby on Rails היה הדבר החם, Node.JS כבר היה (אבל לא כזה חם) - ומאז זרמו הרבה קומיטים ב-Github, וכל אחד בחר כמה נקודות להתייחס אליהן.הצוות עצמו עבר הרבה תהפוכות במהלך השנים, ואלה שמות (מאז דצמבר 2012) - עידן, אבנר, רן ודותןאורי הצטרףרן, אבנר ודותןרן, אלון ודותן בהרכב הנוכחיפרקי 1 באפריל (38, 47)- המצאת שפות תכנות, תוכניות הגירה לבכירים בעולם התוכנה, Frameworks חדשניים ופיקטיבים לזמנם, חלקם פשוט הקדימו אותו . .למשל ה - Super Simple Storage Service - S4עלייתו הצפויה לארץ של Werner Vogelsשירותי התמלול של Amazon עכשיו תומכים בעוד שפה, כך שהראיות רק מתגברות . . .ה - D4: Directed Data Driven Document - מוצר שבאמת יצא בסופו של דבר (עם ראשי תיבות קצת שונים אבל אל תיהיו קטנוניים).הכרזה על Angular 3 לפני שיצא 2 - ואז הם הכריזו על 4 . . .הענן של Facebook: ה-Like Storage שיתחרה ב-S3ועוד שלל נבואות והצלחות ענק - בתקווה לעוד בפרקי 1 באפריל הבאיםשפות תכנות וטכנולוגיות חדשניות שנסקרו במהלך השנים - היו הרבה . . . Go, Rust, Kotlin, Elm, Crystal, GraphQL, Swift, Let’s encrypt- שמעתם כאן לראשונה (אולי, לפעמים).רמזים מוקדמים, נבואות והימורים, כולל מי ינצח? Go vs. Rustיש חדשות גם בנושא הזהעל GraphQL רן שמע מדותן ואימץ בחוםגם Go ו-Let’s encrypt ועוד - לומדים ומיישמים וזה נחמדוהיו גם שפות תכנות מטופשות (עד שיוכח אחרת) שיצא לסקור - כי Borland C זה היסטוריה עתיקה - יש את ArnoldC: שפת תכנות שבנויה כולה על שורות של ארנולד שוורצנגר. אפשר לכתוב בזה תוכניות, בטוח נמצא ב-Production אצל מישהו (אחלה Job Security, נראה מי מעז למחוק)שפה שימושית לא פחות (כי קשה) - Rockstar: שפה שמורכבת מבלדות של רוק כבדעם יתרון אחד לא מבוטל - לגמרי לגיטימי לרשום בקו”ח שאתם Rockstar Developerאיפה שפת Ninja שתהפוך את הקו”ח למושלמים?אם שפות תכנות היו כלי רכב? בלי הגרסא הישראלית של Java בתור סובארו פשע עם עבירות אינסופיתואיך אפשר בלי המועמדים לנשיאות ארה”ב כשפות תכנות . . .פרק ה Way Back עם “חדשות מפעם” - הכרזת Unix, חדשות על VI - ואלה רק הדברים ששרדו כדי שנוכל לצחוק עליהם1976 - הכרזה על VI (עוד לא VIM)1979 - תור Bash1991 - מודמים מזנקים לעתיד ומגיעים למהירות המדהימה של 14.4K!1993 - לינוקס!עוד שפה עם עליות וירידות לאורך השנים - Dartהתחילה כהבטחה גדולה, נראה היה באיזשהו שלב שנעלמה, עד ש . . נראה כמו סוג של קאמבק כחלק מ Flutterגם על חזרתה של Dart הוכרז באחד מפרקי 1 באפריל, עוד לפני שהיא ידעה שהיא כזובאמת… באמפרס 38 - רן מספר ש Dart עומדת להחליף את javascript  בדפדפן כרום (הוכרז בגוגל נקסט האחרון)וזה לא נגמר - גוגל מכריזה על Dart 2 כאשר אם בעבר לא היה ברור האם Dart היא שפת לקוח או שרת הדגש הוא ש Dart היא שפה בה האופטימיזציה היא לצד לקוחההתערבות המפורסמת מכל - Go vs Rust"הCTO של אמזון מהמר על RUST." - בפרק 19 . . .לקח לו בערך 4 שנים ו-35 פרקים לכתוב את firecracker מהפרק הקודםכנראה שהוא עובד על זה רק בטיסות, או שהוא עובד ממש לאטהתחרות בין “חלודה” ל-”קדימה” נראית קצת לא הוגנת, ועדיין . . .הייתה גם ההכרזה על Swiftהמון התלהבות, Swift“ open source like” , נראה כמו שפה מאוד מעניינת ו . . . ובכן, לא.עוד ב-2015 כש- Kotlin הייתה בפיתוח, אמרנו שהיא שפה מעניינת כי היא דומה ל-Swift . . למובייל Swift דווקא כן תופס, ל-Server פחות - הימרנו על יותר מזהנושא דומה - Redux (באמפרס 24) - דותן היה הראשון לזהות, ומאז התפוצצות ענקית, כולל מעמד סלבריטי ל- Dan Abramovהנה שיחה מעניינת איתו, סוג של סיפור סינדרלה“30 שורות קוד”, אבל הגישה של ללמד מפתחים להיות יותר טובים עשתה אימפקט משמעותיאפשר להגדיר את React hooks כסגירת מעגל אבל עדיין טרי מכדי להיות נוסטלגיהאי שם ב-2012 דיברנו על ES6 ודברים חדשים ב-JavaScript“הדבר החדש הזה” . . . הרבה מזה קרה, הרבה לאגם סוג של תזכורת למי הם Addy Osmani ו-Yehuda Katz, שניהם עשו המוןההרצאה הנבואית על The Birth & Death of JavaScript נראתה בזמנו מצחיקה, היום נראה שהכל היה נכוןאפקט 1 באפריל כנראה לא ייחודי לבאמפרס, ונראה ששווה לשים לב לכל שטות לכאורה שאומרים על JavaScriptוזה מאנשים שלא היו מאוהדי TypeScript בהתחלה (בלשון המעטה), ודיברו בהערכה על Flow של פייסבוק.הגענו ל-2014 - הזכרנו את Jim Weirich שנפטר - איש מאוד נחמד שכתב המון מהתשתיות של Ruby ועשה המון למען “ארגונומיה של קוד”.זו גם הייתה שנת ה-Hitler memes  . . .שנה שבא Clojure פרץ ולקח הרבה מפתחי Ruby איתוהיום זה די קרס לתוך איזושהי נישה, אז זה נראה יותר גדולגילוי נאות - החברה שבה רן עובד עובדת לא מעט עם Clojure, יש מצב שזו הנישהבאותו שנה MongoDB היה בדיחה בניגוד לעכשיו? השמועות אומרות שעכשיו זה בסדר, ואם כותבים לתוכו משהו יש סיכוי סביר שיהיה אפשר לקרוא את זה אח”כ. לא ש Write-Only זה רע בהכרח.שילוב של XML או HTML בתוך קוד? נשמע אז לא משהו. בדיעבד JSX לא כזה רע.להגנתנו - ה- Homepage היה מאוד לא מזמין ולא נגיש. לא עושים דברים כאלה היום.2016 - מסתבר שדיברנו Parse -סוג של Serverless של Facebook (אחרי רכישה)אז זה מת, אבל נתן חיים להרבה דברים אחריםהתחיל כסרבר למובייל (ודואג ל-Push), כנראה כסוג של אסטרטגיה ליצור פלטפורמה שמפתחים עובדים עליה; מאז די עבר להם והאסטרטגיה השתנתהמכאן והלאה Firebase צמח, אולי זה מה שנתן חיים לכל היקום ה-Serverless ? אולי.אין סרבר - אין דאגותרן מאוד התלהב בזמנו מ Lambda, אכל הרבה חצץ בהתחלה אבל חווייה חיובית בינתיים.כולם רוצים להיות Serverless, גם מי שיש לו שרתים פיזיים. השם קצת בעייתי כי יש בסופו של דבר יש מכונה בקצה השרשרת.ועוד משהו מרן - !Last commit before leaving a jobשישים שורות קוד של רשע טהור, כולל הגדרת פאי ל-3.2, הגדרה של IF כ-While ועוד פניניםכולל דירוג של רמת האכזריותכולל חלק שלם של Locksנדרשת גרסא חדשה בעוד שפות - מי עוזב עכשיו עבודה עם C?! צריך להרים שרת במיוחד?הויכוח בין Wix ל-WordPress סביב שימוש בקוד פתוחהעלה את נושא המודעות לרשיונות השונים וחשיבות ההבנה של מה שיושב בכל חברהרכיב של Wix עשה שימוש (תמים?) ברכיב של WordPress; אולי היה עובר בשקט אלמלא היה מדובר במתחרות.מרגיש כאילו זה היה אתמול . . .ולחובבי Ruby - מהלך להגדרת השפה כ-Spec, מתוך מחשבה ליצור כל מיני וריאנטים של השפהעזר לכל השפות להתפתח ולגדול - ודי למות . . . הכל התכנס לכדי משהו שלא ממש קייםצוות ההובלה של Ruby לא עשה מספיק? צוות יפני (Matz) שהיום הוא חלק מ-Salesforce, ופחות מתקשר בשפות שאינן יפנית ולא ממש פתוח לעולם . . .להשוואה - בשנתיים האחרונות רואים קפיצה משמעותית בפייתון, ו-Ruby נשארה די סטטיתאבל כבר הספדנו את  Dart אז אוליסיפור לא נחמד מצד Heroku , שעשו ניתוב לאפליקציות מסויימות ל-compute יותר חלש למשלהאם זה יכול לקרות שוב בעולם של Serverless?יש בכלל הגדרה נורמאלית מוסכמת של vCPU? שאלה טובה . . . אתה לא באמת יודע מי השכן לידך בחווה בסוף היוםהמהירות של כל ליבה לא משתנה משמעותית בשנים האחרונות, יכול להיות שזה חלק מזה.כמה אסימונים שנפלו במבט לאחור - בזמנו, Go נראתה כמו צעצוע מאוד יציב ומאוד פשוט . . שש שנים קדימה זה תפס בצורה מטורפתהתומכים הגדולים דווקא לא באו מתוך Google אלא מבחוץ; בתוך Google נראה לכאורה שיש מעט מאוד פרויקטים ב-Go, נראה שמי שכבר כותב ב ++C או Java כבר לא עובר כל כך מהרלמעט פרויקטים חיצוניים כמו K8S וכו’עדיין מושקעים המון מאמצים ע”י Googleזו עדיין שפת ה-High Performance העיקרית, ויחסית קלה ללימודכבר שפה בוגרת, יש דיבורים על גרסא 2, עם רשימת מפתחים מאוד מכובדתעוד בעבר הרחוק של פרק 18 דובר על “Kubernetes פלטפורמה של גוגל להרצה של Docker”הפריצה בשנתיים האחרונות מדהימה (מאז הבעת האמון של Outbrain?)לכל העננים המרכזיים יש שירות מנוהל ל K8S; טוב יותר או פחות אבל בכל מקרה סימןכש-Docker יצא, זו הייתה תוכנה ב-Go . . . בזמנו Solomon Hykes תיאר את זה כמנוע לניהול של קונטיירים בפייתון, וכשזה נראה לא טוב אז החליטו ללמוד Go ולעבור. ואז להפוך את זה ל Open source . . .תואר מלכת הדרמות - Node! הייתה תקופה שזה היה כמעט בכל פרקהפיצול המדובר בין Node לבין io.js, ואז האיחוד הרומנטי בחזרהכולל תקופה שבה בכל פרק היה אייטם על מעבר של עוד חברה מ-Node ל-Goסכסוכים פנימיים, מעברים דרמטים, מפתחים שעברו, הרבה ענייןועד הפרק האחרון עם I don’t know what to say . . .קצת כמו מה שהיה פעם עם Windows - מערכת מאוד נפוצה --> כולם מנסים לפרוץ --> מוצאים יותר פרצותקצת בלי ששמנו לב, Microsoft חזרה מהצד האפלתומכת בקוד פתוח, קונה את Github, חביבת המפתחים . . . והגיהנום לא קפא.החלפת המנכ”ל עשתה פלאיםקצת חזרה ל 2012-2013 - React מחקה עולם שלם . . .מישהו זוכר Prototype? מי הימר על jQuery? רן . . .ובסוף (נכון לעכשיו) React השאירה לכולם אבקועדיין - Angular עם בעיות אבל לגמרי חיה, ו-View צומחת יפהמלפני React לא נשאר כלוםגיוס הפך לממש קשה . . .יש זמן קבוע ואינסוף כלים ואין זמן להתעמק?פערים בין היצע לביקוש? 15,000 מפתחים חסרים?לא היו כל כך הרבה שפות? התרגלו לחפש את ה-Buzzwords וקשה למצוא את הבנאדם הספציפיצריך ידע כללי טוב ולהכיר את ה-framework הנכון, ופחות קריטי לתכנת ממש טוב?יש מוצרי חלב עם תוקף יותר ארוך מטכנולוגיות JavaScript . . .וכולם רוצים Full stack - הרבה יותר רחב, אולי פחות מעמיקהטכנולוגיה הכי חמה יצאה אחרי תחילת הראיון, לא רלוונטי . . .הרבה פעמים הכישורים הנדרשים על מנת להביא Value ללקוחות מהר אינם כוללים תואר שלישי במדעי המחשבהשאלה מה קורה לאורך זמן - הטרנדים לא תמיד עובדים טוב בכל שלושת הצדדים של המטבעלהתעסק באופטימיזציה ולהמציא את הגלגל מחדש במקום להשתמש בספרייה קיימת לא בהכרח משרת היטב את הלקוחות, יש בזה כנראה גם אלמנט תרבותייכול להיות שמי שיש לו בסיס יותר רחב, יכול גם ללמוד יותר - ובכל מקרה רמת האבסטרקציה הנדרשת ממפתחים צריכה לעלות כל הזמן, לפעמים זה אומר ריחוק מה”ברזלים” ומ”CS Basics”עד כאן לפרק היובל +5. בבאמפרס הבא חוזרים לחדשות באמת חדשות.הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול