Podcasts about soluto

Today, our guest is Shira Gershoni, seasoned product management executive, with 15 years of experience in eCommerce and SaaS product development across North America and Europe. Shira started her career in web development and later transitioned to technical product management while at Eternity-IT, followed by leadership positions at NeoGames, Soluto, and Asurion. On today's episode, Jennifer talks to LogRocket's CEO and Head of Product, Matt Arbesfeld, about the significance of focusing on creating omnichannel experiences, why using AI enhances user experiences and making data-driven decisions, and how a culture of iteration in product is more impactful than aiming for perfection. Links https://www.linkedin.com/in/shira-gershoni-vp-product/ https://blog.logrocket.com/product-management/leader-spotlight-shira-gershoni/ Chapters 00:00 Intro 00:05 Omnichannel in practice 01:51 Understanding personas 02:56 Challenges in omnichannel transition 04:22 Managing digital and physical products 06:24 The role of product managers 13:00 Kickoff meetings and iteration 22:04 Leveraging AI in product management 26:27 Outro What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces UX and technical issues impacting user experiences. Understand where your users are struggling by trying it free at LogRocket.com (https://logrocket.com/signup/?pdr). Special Guest: Shira Gershoni.

In the newest episode of the #BWR podcast, we interviewed business attorney Soluto Uba of the Uba Law Group.  Soluto specializes in business formation, tax planning, and protecting your business in the event of being sued.  We speak about the 4 types of business structures, Trademarks and Copy-writes, and what it looks like to build wealth through ownership.  If you're interested in advertising on the Black Wealth Renaissance podcast, please email podcast@blackwealthrenaissance for further inquiries. Leave Us A 5 Star Rating & Review ⭐️⭐️⭐️⭐️⭐️ If you love the show and want to show us some support donate below.  Donate here GET TICKETS TO UPCOMING EVENTS

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

On this weeks episode, I was able to speak with Soluto Uba aka The Entrepreneur Lawyer. We had the chance to discuss all things business from a legal perspective. Soluta is a lawyer with his own firm dedicated to helping entrepreneurs get their business affairs in order so that the business is setup properly and protected. We spoke on a plethora of things from understand a paper LLC vs. Performing LLC, to setting up an LLC properly, and more. Tap in with Soluto to make sure your business is setup correctly so that you are properly protected legally. Soluto's IG: @theentrepreneurlawyer Soluto's Twitter: @MrUba Please Rate, Leave a Comment, and Subscribe to my podcast! ⭐️⭐️⭐️⭐️⭐️ Follow WFTK on Social Media: Instagram: @WealthfortheKulture Twitter: @Wealth4Kulture Youtube: Wealth for the Kulture - https://youtube.com/channel/UCoNIXR5oBYD8PQ4GHwxsyzg --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/wealthforthekulture/support

[קישור לקובץ mp3] שלום רב וברוכים הבאים לפרק מספר 416 של רברסים עם פלטפורמה - התאריך היום הוא ה-27 ביולי 2021, ואנחנו נפגשנו ביוקנעם באולפן הבייתי יחד עם יונתן ואסף - היי חבר'ה, מה נשמע? - יונתן, מה שלומך? מתאושש מהג'ט לג הקטן? - (יונתן) כן, הבאתי לך טובלרונים לאחרי . . . (רן) איזה כיף זה הטופי הזה שנתקע בין השיניים . . . - אז אסף - ברוך הבא! (אסף) תודה רבה(רן) היום אנחנו נדבר על נושא Frontend-י - אנחנו לא מדברים הרבה על נושאים Frontend-ים, אבל היום אנחנו נקדיש את כל הערב הזה ל-Frontend - ובעיקר, באופן ספציפי - ל-State Management ב-Frontend.אז עם זה אסף מגיע אלינו - אז אסף, בוא נכיר אותך: מאיפה אתה בא? מה אתה עושה? ספר לנו קצת עליך וקצת על החברה שלך.(אסף) אז אסף קרינצה, אני בא מתל אביב עד לפה ליוקנעם . . .אני מתכנת - התחלתי לתכנת מקצועית בערך לפני עשר שניםהתחלתי את הקריירה ב-CheckPoint, הייתי שם בהתחלה בתחום שהוא יותר Security, אחרי זה עברתי להיות מתכנת ואז ראש צוותאחרי זה עבדתי ב-Microsoft וב-Soluto [עדיין טרי - 413 GitOps with Yaron from Soluto]לאורך השנים עבדתי גם ב-Backend וגם ב-Frontend - וב-Frontend יצא לי להתעסק בהרבה State Management Solutions: לחוות אותם ב-Production, לעבוד איתם בצוות - וגם בפרוייקטים בבית התנסיתי בכל מיני.אחרי Soluto - בעצם בספטמבר האחרון - עזבתי את העבודה, אני ועוד שני חברים טובים שהם גם שותפים, אחד מהם עבד איתי ב-Soluto ואת השני פגשתי עוד ב-CheckPoint - והקמנו חברה בשם livecycle.כש-livecycle זו חברה שעוסקת במוצר עבור צוותי פיתוח - אנחנו מרימים סביבות - Preview Environments - מתוך ה-Source Code של הלקוחות שלנובעצם, הרעיון הוא שעבור כל Change, כל Commit - אנחנו עושים תהליך שהוא דומה לתהליך CI, של לבנות - לעשות Build - למוצר, ואנחנו גם עושים לו Running, בענן.בעצם, יש “סביבה חיה ובועטת” של כל גרסא של המוצר - בענן - שאפשר לשתף אותה.מעבר לזה, On top that - אנחנו שמים כלי קולברציה (Collaboration Tools)לדוגמא, אפשר לדמיין שיש מעצבת בצוות, ומתכנתתהמתכנתת עשתה שינוי בקוד - ושולחת למעצבת, שאולי עיצבה את הפיצ'ר הזה - לינק.המעצבת תוכל להיכנס ללינק, לראות גרסא חיה שלו - ממש גרסא של המוצר, לא איזה Mock - וגם תוכל להגיב שם, עם הכלי קולבורציה שלנוהיא תוכל לשנות CSS - נגיד “ה-Margin לא מספיק טוב”היא תוכל לעשות Screenshot ישירות, בלי Tooling חיצונילהקליט וידאוכל הדברים האלה באים “בחינם” - בלחיצה של לינק . . . וכל זה רץ לו על הדפדפן.(רן) אז אתה אומר - יצרת Pull Request או Merge Request, תלוי באיזו פלטפורמה אתה משתמש - ואז באופן אוטומטי נוצר לך איזשהו Preview link שאותו אתה יכול לשלוח, עוד לפני שעשית Merge, זאת אומרת - אתה לא צריך ללכת ועשות Deploy כדי שהסיפור הזה יעבוד, ופה חוסך זמן ומייעל את ה-Cycle . . .(אסף) נכון . . .(רן) בסדר . . . אצלכם, דרך אגב, יונתן - יש פתרונות בסגנון הזה?(יונתן) Preview כזה אין לנו . . . יש לנו סביבות Pre-Production, שלשם אנחנו מעלים גרסאבאמת בדרך כלל אחרי Merge, כמו שאתה תיארת.(רן) כן, אוקייאנחנו בעצם נפגשנו פה כדי לדבר על State Management ב-Frontend.עכשיו, אני מניח שכל מי שמפתח Frontend בעשור האחרון מבין על מה מדובר, אבל בוא נחבר גם את מי שהוא לא מפתח Frontend, זאת אומרת - למה צריך State Management?יש לי CSS, יש JavaScript, יש HTML . . . על איזה State בדיוק אנחנו מדברים פה? למה צריך State Management?(אסף) אחלה . . . אז אפשר באמת להתחיל מלהגיד מה זה State, ומה זה בעצם עושה באופן כללי, וספציפית באפליקצית Web.אז אפשר להגיד ש-State זו איזושהי “פיסת אינפורמציה”, שמגדירה איך נראית האפליקציה בכל רגע נתוןאיך היא נראית ואיך היא מתנהגתלדוגמא - זו הדוגמא הקלאסית, כשמדברים על State Management, יש כזה את ה-”Hello World” שזה ה-To-Do Applications - כשיש לך רשימת To-Do's כזאת, ה-State יכול להיות האינפורמציה, Array של To-Do's, כשכל אחד מה-Item-ים ברשימה יכול להיות אובייקט - שיהיה לו Title ויהיה לו “?Is Completed”, האם המשימה בוצעה או לא.זה ה-State.עכשיו, יש לנו את האפלקיציה - היא לוקחת את ה-State הזה, ומרנדרת (Rendering) איזשהו View.אפשר להסתכל על זה כמו איזושהי Pure Function, שעבור כל State תייצר אפליקציה אחרת, ועבור אותו ה-State תייצר בדיוק את אותה אפליקציה.הרעיון של ה-State Management זה איזה-שהם כלים וקונספטים שעוזרים לנו לנהל את הדבר הזה.(רן) הזכרת מקודם View - אז יש את המודל הקלאסי, ואולי קצת ישן ומאוס, של Model-View-Controller - אז באלגוריה הזאת, ה-State הוא למעשה ה-Model?(אסף) נכון - ה-ה-State הוא למעשה ה-Model, ה-View זה יכול להיות . . . אם זה נגיד, MVC שמתרדנר (Rendered) בשרת, כמו Ruby-on-Rails או PHP או Laravel או כאלה דברים, ה-View הוא HTML, שהשרת מחזיר ללקוח - והדפדפן “מצייר” מזה אתר.(יונתן) אני חושב שפעם, בעצם . . . יש מעיין Shift כזה ל-Frontend . . . פעם, ה-Database באמת היה ה-Database, ה-Server היה עושה את הלוגיקה, מרנדר אפילו JSP וכל מיני כאלה - וה-Browser היה רק מציג.עכשיו, יש Shift כזה שמאלה ל-Frontend, ששם כבר הלוגיקה - ולכן חסר שם איזה משהו . . .(רן) כן, אני מסכים - ככל שיותר לוגיקה עברה ל-Frontend, ככה נדרש יותר תחכום, ולכן גם נדרש איזשהו State Management - וכנראה שעוד הרבה דברים אחרים. לא רק זה, אבל זה לגמרי אחד מהם.עכשיו - State Management גם מגיע עם רכיבי View בדרך כלל, נכון? יש איזשהו קשר הדוק - אני מניח, למשל, שכל מי שכתב אי-פעם ב-React, כנראה גם מכיר את Redux ואולי גם עוד כמה חבילות.למה . . . נשאל את השאלה הזאת ככה: האם באמת “הצימוד” הזה הכרחי? מה המוטיבציה לצימוד הזה? מה אנחנו מרוויחים מהצימוד הזה? או לחילופין - האם אפשר להפריד ביניהם, לצורך העניין - להשתמש ב-Redux עם Angular או Whatever, והאם אפשר להרוויח מזה משהו פה?(אסף) אחלה - אז כמו שאמרתי, יש פה שני דברים שונים: אחד - זה האם כשאתה משתמש ב-React, צריך להוסיף לזה, On top of that, גם Redux?; והשני זה “האם Redux עובד גם עם דברים אחרים?”.אז אם אני אענה על השאלה השנייה קודם - Redux הוא לא Coupled ל-React: זו ספרייה שיכולה לעבוד עם כל מיני ספריות, והיא יותר High-Level.יש Binding מ-Redux ל-React - זה נקרא React Redux, שזה מצמד את React ל-Redux, אבל באופן די גורף - לרוב ישתמשו ב-Redux עם React, וזו גם הספרייה פופולארית ביותר.אני הסתכלתי לא מזמן ב-npm, ב-Weekly Downloads, ו-Redux הוא 90% בערך מהנפח של הספריות שהסתכלתי עליהן.אני לא יודע כמה קורלציה יש לזה לשימוש אמיתי, אבל אם זה אומר משהו, אז Redux היא סופר-סופר פופולארית.(רן) כן - ואני חושב, דרך אגב, ש . . . מי שמפתח Frontend בודאי מכיר, אני אתרגם רק למי שאינו מפתח Frontend כנראה - אחד הדברים שהכי קוסמים ב-Redux זה הפשטות שלהזו ספרייה שהיא (א) מאוד מאוד קטנה ו-(ב) יש המון המון Tutorials על איך לכתוב Redux בשביל עצמך - מתוך מטרה שהמפתחים יבינו באיזה כלי הם משתמשים.אז לא כל ספריות ה-JavaScript פשוטות, אבל Redux זו שפה פשוטה - אבל אלגנטית, וזה היופי שלה.אבל Redux זה חדשות של לפני . . . כמה? 6-7 שנים?(אסף) 2014 זה היה, אם אני לא טועה [2013?] . . . זה היה ההרצאה של Dan Abramov, שבה הוא הכריז על הספרייה.(רן) כן, אז 7 שנים, אולי יותר - ומאז הרבה מאוד דברים קרו - אז בוא נדבר על מה קורה היום . . .ביום-יום - מה אתה עושה? אתה הולך ופותח פרויקט ו . . . ? דבר ראשון אתה מביא Redux? איך זה נראה?(אסף) אז זו שאלה מצויינת, ובאמת זה תלוי מאוד בצרכים שלך, של האפליקציה עצמהצריך לשאול מה עושה האפלקיציה? מה המורכבות שלה? האם בכלל צריך State Management?אפשר אפילו לקחת קודם צעד אחורה - ולשאול האם בכלל יש State? לא לכל אפליקציה יש State, כמו שיונתן ציין.פעם, אם אנחנו הולכים ממש אחורה, ל”תחילת האינטרנט” - אז אתרים זה היה משהו מאוד פשוט: זה היה הטקסט, התמונות, מדי פעם היה איזה Form . . . אבל זה מה שקרה.וככל שעבר הזמן, הדפדפן ניהיה דבר מאוד מורכב, מעיין “מפלצת” - זה היום חזק כמו מערכת הפעלה שלמה כמעט, אפילו דפדפנים יכולים היום להריץ Server-ים . . . אני ראיתי ש-StackBlitz מריצים את Node בתוך הדפדפן - אתה יכול להריץ Node Server שמרים לך Web Server, וחושף IP שאתה יכול, דרך הדפדפן שלך, להיכנס ל-IP שהדפדפן מרים . . . זה די Mind-blowing.(רן) רקורסיה . . . זו הכותרת.(אסף) בדיוק . . . אז דפדפן זה משהו מאוד חזק, ואפשר לעשות איתו דברים מטורפים.אבל קודם כל, השאלה שצריך לשאול, בכלל לפני ששואלים איזו בספרייה משתמשים, זה האם צריך ספרייה כזאת?אם החלטנו שאנחנו משתמשים ב-React, כספרייה - כי גם את זה אנחנו לא חייבים - אז גם React, לכשלעצמה, יש לה פתרונות לניהול State.כי React באה עם כמה APIs נוחים לניהול State - אני מדבר ספציפית על . . . אפשר לעשות את זה בכמה דרכיםאו בצורה הישנה, שזה דרך ה-Classאו דרך Hooks, שזה משהו קצת יותר חדש.אני אדבר על ה-Hooks, כי זה קצת יותר נוח, אבל אותם עקרונות בדיוק אפשר לעשות גם ב-Classes . . .(רן) נעשה פה רגע איזו עצירה - יונתן, דיברנו קודם זה שלפחות היסטורית, רוב ה-State היה נשאר בצד של השרת והיה מוחזק ב-Database-ים, והייתה איזושהי שכבת Rendering - שגם היא הייתה נמצאת הרבה פעם בצד של השרת.ואז הזכרת - אסף - שהדפדפנים היום הם דווקא די חזקים, ושאפשר לעשות בהם כמעט הכל - ובין השאר, יש בהם גם Database-ים.ועכשיו, נשאלת השאלה - האם יש קשר בין ה-State, שעליו אנחנו מדברים, לבין ה-Database-ים שקיימים היום בדפדפנים? לצורך העניין - האם הם שומרים ב-Database-ים המקומיים שלהם את ה-State, או שזה State שהוא מתדנדר (Rendered)? זאת אומרת - ברגע שאתה עושה Refresh לדף, הכל נעלם ומתחילים מחדש?(אסף) ה-State שאני אוהב וה-State-ים שאני מדבר עליהם - הם לרוב נשמרים ב-RAM, בזכרון, וזה אומר שזה יתנדף ברגע שירפרשו (Refresh) את העמוד.כמובן שאפשר את כל ה-State הזה להעביר אל ה-Local Storage או עם פתרונות Database-יים מקומיים שיעשו את זה Persistent over time.זה במיוחד יהיה יותר קל ויותר נעים עם ספריות כמו Redux, ששומרים הכל במקום אחד - אתה עושה לו פשוט Dump וטוען אותו בחזרה.בדרכים אחרות, אם אתה שומר את ה-State שלך בצורה קצת יותר מבולגנת ב-RAM זה אולי יהיה קצת יותר קשה, אבל אם אנחנו הולכים, נגיד, על משהו כמו Redux, או Recoil, שגם לו יש Snapshot ו-Store שמסדר הכל במקום אחד - או MobX-State-Tree, שזה גם פתרון כזה - יהיה מאוד קל לעשות Dump של הזיכרון הזה אל ה-Local Storage, לדוגמא, שזה Persistent Storage, כמו Database - ולטעון את זה בחזרה כשטוענים את האפליקציה.(רן) “מאוד קל” במובן הזה שזה פשוט String JSON, ואתה יכול לכתוב ולקרוא אותו לעשות Serialization או De-Serialization?(אסף) כן - בגלל שכל ה-State נמצא בעצם באובייקט אחד, אני יכול לעשות לה סריאליזציה (Serialization) ל-JSON, לשמור אותו כ-String ב-Local Storage, לטעון אותו, לעשות לו דה-סריאלזיציה (De-Serialization) - ולהשתמש בו שוב.(יונתן) אם אני, נניח, מתחיל לכתוב אפליקציה חדשה, ואני עוד לא יודע כמה היא תסתבך, כמה גדול זה יהיה . . . - האם היית ממליץ לי, מההתחלה, להשתמש ב-State Management, או לחכות שזה ממש “יצעק”?(רן) זה לא כמו השאלה על Unit Testing? . . . “אני מתחיל משהו קטן, איזשהו פרויקט-צד קטן, לא נראה לי שזה הולך להיות מסובך, אני לא כותב טסטים” . . . מפה לשם - אחרי שנה אתה לא מוצא את הידיים ואת הרגליים . . . (אסף) כן, לגמרי . . . אז זה עניין של גישה.אני, כשאני מתחיל משהו חדש, אני אוהב להתחיל את זה עם כמה שפחות Boilerplate וכמה שפחות דברים, הכי נקי שיש, וכשאני צריך עוד ועוד דברים - אני עושהאני אבין בעתיד, כנראה, גם מה הצרכים שלי, ואני אדע לבחור איזה מהפתרונות State Management . . . כי שוב - זה לא סטנדרט . . . אין סטנדרטיזציה בנושא, אז יש כל כך הרבה ספריות וכל כך הרבה דעות, וזה מסוג הדברים שמתכנתים אוהבים להיות מאוד דעתניים כלפיו.(יונתן) אז המיגרציה (Migration) הזאת, מלהיות בלי State Management לעם - למשהו ש . . . זה מסובך לעשות את זה? זה re-factor ש”ישכיב” את הצוות או שזה “מכה קלה בכנף”?(אסף) אז אני חושב שזה תלוי מאוד ב- State Management solution שאתה בוחר בולדוגמא, MobX זו אחת הספריות הפופולאריות - כנראה השנייה-הכי-פופולארית אחרי Redux - זה מאפשר לך לעשות את ה-Transition הזה בצורה די נוחה, כי זה משתמש באיזשהו “קסם” שמאפשר לך לעטוף אובייקטים רגילים של JavaScript ולהפוך אותם ל-”React-ביים”.מה זאת אומרת -”React-ביים” [חוץ ממשהו שממש קשה להעביר לטקסט ככה?] - זאת אומרת שאם ה-State הזה מעודכן, אז ה-View שלנו גם יתעדכןזאת אומרת ששינינו . . . נגיד בדוגמא של ה-To-Do List, שינינו את ה-Data, את ה-Array הזה של ה-To-Dos? - והקומפוננטות (Components), ה--ים האלה, שמציירות את זה על המסך, תתעדכנה גם כן.ובגלל שזה משתמש באיזשהו “קסם”, שנקרא Proxy Object של JavaScript או Getter ו-Setter של ES5 - אלו שתי דרכים לעשות את זהזה בעצם “דורס התנהגות” של מה שאנחנו עושים, De-reference לאובייקט, כשאנחנו ניגשים אליו.אז מאחורי הקלעים, אתה משתמש בזה כמו אובייקט רגיל, אתה עושה State.ToDos[7].Title - ועורך את זה.ומאחורי הקלעים, MobX עשתה לך Subscription כשהשתמשת בזה עבור הקומפוננטה (Component) שמשתמשת בזה, והיא תדע לעדכן את הקומפוננטה בכל פעם שעדכנת את ה-State.אז זה יהיה מאוד מאוד נוח . . . יכול להיות שכתבת את הדבר הזה כאובייקט JavaScript רגיל, ואתה רק מוסיף MobX ועוטף את זה בכמה פונקציות שהספרייה מביאה לך - ואתה די מסודר, יש לך State Manager . . . בספריות אחרות, נגיד Redux, זה משהו שהוא הרבה יותר opinionated, והוא קצת יותר מורכב.אתה צריך לנסות הרבה יותר דבריםוזו גם אחת הביקורות הכי גדולות שיש על הספרייה הזאת - זה שצריך ללמוד הרבה, ושאתה צריך לכתוב הרבה קוד בשביל להשתמש בזה.(רן) בוא נחזור רגע ל”קסם” - כי קסם זה כיף: אז יש Attribute - אתה אומר נגיד, ToDos[1].Value = “לאסוף כביסה”, ואז, בעצם, אתה אומר שיש איזשהו רכיב שעשה איזשהו Subscription ל-Setter הזה, והוא עושה “Hijacking” לקריאה הזאת או עם Proxy או טכנולוגיה אחרת שהזכרת את שמה, והוא בעצם “תופס” את הקריאה הזו, ואולי הוא עושה Set ל-Value - אבל הוא גם מפעיל איזושהי שרשרת של קריאות, שבסופו של דבר מפעילה את ה-UI.עכשיו, זה נחמד ברמת השימושיות . . . השאלה, אם אתה מכיר את הקונספט הזה, מה שנקרא The Fallacies of distributed systems - שבעצם זה בא ואומר שכאילו אתה מפעיל איזושהי קריאה, ואתה לא יודע שהקריאה הזאת רצה על איזשהו שרת מרוחק, ולכן אתה גם לא יודע מה כל הדברים הרעים שיכולים לקרות בדרך . . . אז אתה לא מטפל נכון בשגיאות, אתה לא יודע כמה זמן זה יקח, אתה . . . זאת אומרת - זה נראה קל, אבל אתה בעצם “מחביא” מאחורי זה הרבה מאוד דברים שגם יכולים להשתבש, ואם אתה לא מבין שזה מה שיקרה, אתה יכול לטעות, זאת אומרת - יהיה לך UI שהוא Sluggish ועוד כל מיני כאלה תופעות . . . אולי לא תטפל נכון בשגיאות וכו'.אז איך . . . יש פה איזשהו Trade-off בין פשטות השימוש לבין היכולת שלך לשלוט בהתנהגות בצורה שהיא Fine-grained . . . (אסף) נכון מאוד . . . MobX, כספרייה, זה משהו שהוא יותר Tool, שהוא נורא לא Opinionated.הוא מאפשר לך איזושהי יכולת, שנותנת לך לעשות Subscription ו-Reactiveness ל-State, בלי לעשות הרבה Boilerplate - אבל זה לא אומר שאתה חייב להשתמש בזה בצורה הכי פשוטה.אתה יכול לעטוף את זה בדברים שיעזרו לך לפתור את הבעיות שציינת - של Observability ושל Debugging יותר נוח.האמת שהיוצר של MobX כתב עוד ספרייה, שקוראים לה MobX-State-Tree, שהיא כן Opinionated, ומשתמשת ב-MobX בתור כלי, מאחורי הקלעים, לעשות את הפעולות היותר . . . של ה-Reactivness.אבל היא מאוד Opinionated - יש שם Store, ל-Store יש Type-ים שאתה רושם אותם, איזשהו מודל . . . אתה רואה בכל פעם לאן כל דבר הולך ואתה יכול ליצור, מתוך זה, Snapshots - בדומה ל-Reduxזאת אומרת - זה משלב, באיזשהו מקום, את הכיפיות והקסם של MobX, אבל את ה-Rigidness וה”נוקשות” הזאת של -Redux, שגורמת לך גם לדבג (Debug) קוד בצורה יותר נוחה וגם להבין מה קורה כשדברים משתבשים.(רן) כשדיברנו בטלפון, בשיחה המקדימה, דיברנו על ספרייה שנקראית Recoil, שהזכרת את שמה מקודם - מה מעניין בה? מה מיוחד בה? מתי אני ארצה להשתמש בה ולא באחרות?(אסף) אחלה, אז Recoil . . . אולי לפני שנדבר על Recoil, נדבר טיפה על קונטקסט, כי הרבה מהדברים שם הם סוג של פותרים דברים שהיה בעייתי עם קונטקסט, עם New State.אז אם מסתכלים רגע על ה-API ש-Redux מביא איתו Built-in, בלי להתקין שום ספרייה חיצונית, אז יש לנו שני דברים עיקרייםיש לנו useState, או useReducer, שזה תחליף ל-useStateויש לנו את Context.עכשיו - useState ו-Context עושים שני דברים קצת שונים - useState מאפשר לכל קומפוננטה (Component) לשמור State לוקאלי עבורה, שהוא Persistent בין Render Callsזאת אומרת שאם אני אקרא ל-Render עוד פעם, יהיה לי את אותו State.ובנוסף, זה נותן לי את ה-Reactiveness הזה, כמו שדיברנו - זה מרכיב חשוב בכל State Management.ברגע שעדכנתי את ה-State, עם פונקציה שה-Hook הזה מחזיר לי - ה-setState - אז React ידע לקרוא לי ל-Rendering - אם ה-State המחודשזאת אומרת שברגע שאני מעדכן את ה-State - אני יודע שה-View יהיה “טרי”, הוא יצייר לי את מה שאני רוצה עם ה-State “הטרי” והחדש.(רן) זאת אומרת - כאילו יש את המצב הראשוני, ואחר כך, על כל שינוי, יקראו לך ותעשה Rendering מחדש.(אסף) בדיוק - אני יכול . . . React מבטיח לי את זה, שזה אחלה, זה מעולה.הבעיה עם useState זה שדברים . . . שאפליקציה, כשהעץ-קומפוננטות של React מתחיל לגדול ולגדול, אני רוצה לפעמים להתחיל לשתף State בקומפוננטות שלפעמים הן גם במיקום רחוק בעץ . . . שני עלים שיש להם אב-קדמון משותף, נמוך ביותר, שהוא כמה רמות מעל.ואז זה אומר . . . .(רן) אוקיי - אז אני מסתכל על רשימת ה-To-Do - אז אתה רוצה, נגיד, להציג איזשהו View אחד גדול עם ה-To-Dos, ואולי מימין-מלמעלה גם איזשהו תקציר של הרשימה, נגיד כמה אייטמים נשארו un-checked . . . (אסף) בדיוק - כמה אייטמים נשארו un-checked, ואולי עוד סטטיסטיקות . . . מעיין כזה Dashboard, זו דוגמא מעולה.ובאמת, כדי ששתי הקומפוננטות הללו תכירנה את אותו State - כי אנחנו לא רוצים לשכפל את ה-State, אנחנו יכולים, תיאורטית, לשכפל את ה-State, אבל אז נוצר מצב שבו אני צריך לטפל בעדכון של שני State-ים שונים, וזה יכול ליצור באגים וזה קשה להבין . . . (רן) מה הבעיה? תיקח ספרייה, בטח יש אחת כזאת שעושה את זה, לא? . . .(אסף) יש ספרייה . . . ב-JavaScript יש ספרייה לכל דבר, לכל שורה של קוד יש ספרייה . . . (רן) ראיתי לא מזמן איזשהו API שנקרא is-odd - שמחזיר לך אם המספר זוגי או אי-זוגי . . .(אסף) יש את הסיפור המפורסם של left-pad, שזו ספרייה שהקריסה את כל npm, הקריסה מלא עבודה של מלא אנשים בכל העולם, בגלל שהשתלטו עליה ועשו שם כל מיני דברים . . [היה לא מזמן ב-398 with Danny Grander from Snyk](רן) בסדר - אז אתה לא רוצה לשכפל את ה-State וזה, אני חושב, ברור - אבל אתה אומר שיש פה בעיה עם ה-Set . . .(אסף) כן, ומה הבעיה? יש פה שתי בעיות - אחת זה שאם אני רוצה ששתי קומפוננטות, שנמצאות במיקום מרוחק בעץ, ישתפו את אותו State, אני צריך להתחיל להעביר את ה-State הזה ממקום למקום - זה נקרא Props Drilling, “קדיחת Properties” . . . זה לא נוח, זה אומר שבכל פעם שאני רוצה להוסיף State אני צריך להוסיף את זה בעוד “מיליון מקומות”, קשה לעקוב אחרי זה, מאיפה זה בא . . .(רן) כן, אתה צריך לקודד . . . למעשה, אתה צריך . . .עכשיו כשאתה אומר, אני נזכר שעשיתי את זה, וזה היה מה-זה מעצבן . . . בכל מקום אתה צריך ללכת ולעשות . . . “לפעפע” את ה-Attribute הזה למטה ולמטה ולמטה . . . .ממש עבודה ידנית מעצבנת . . . (יונתן) וזו בעיה גם לפעמים בקוד של ה-Server, נכון? כשאתה מאתחל איזשהו Bin, או איזשהו אובייקט, ורק למטה למטה אתה צריך להעביר אותו . . .(אסף) נכון, Dependency Injection כזה . . .(יונתן) ואם אתה “מתפתה”, אז אתה שם איזשהו משתנה גלובאלי או Database או משהו כזה, ואז אתה . . (רן) זה כשאתה מתכנן להתפטר . . . וכשאתה מתפטר אז אתה לא מגלה . . .(יונתן) אז מה האלטרטיבה ל-Props Drilling הזה? . . . (אסף) אז רק אני אגיד שבנוסף להעברה הזאת, זה גם עניין של Performance, זה בעייתי - כי איך ש-React עובד, ברגע ש-Props משתנה, הוא קורא ל-Render מחדש . . .הוא קורא ל-Render כש-Props משתנה וכ-State משתנה.וכשכל תת-העץ הזה, שבכלל לא משתמש ב-State - כל מה שהוא עושה זה להעביר את זה מפה לשם כשמתרדנר (Renders) - זה פשוט בזבוז של חישוביות . . .אבל באמת כדי לפתור את זה יש איזשהו API שנקרא Context - ו-Context מאפשר להגדיר איזשהו State . . .(רן) הנה המשתנה הגלובאלי שחיפשת, יונתן . . . (אסף) בדיוק . . . אז זה משתנה גלובאלי, שבעצם פותר את העניין של ה-Drilling, כי אני יכול להגדיר את זה ב”אב הקדמון” המשותף הזה, אני יכול להגדיר שם את ה-Context, וזה אומר שכל חלק בתת-עץ, שהוא צאצא של האב הקדמון המשותף הזה, יכול להשתמש ב-Value של ה-Context.וזה מאפשר לי לפתור את ה-Props Drilling - וגם עם זה יש קצת בעיות . . . אחת - גם פה יש קצת עניין של Performance, כי אם אני, נגיד . . . לרוב, מה שעושים זה שעושים Provider כזה, ובתוך ה-Provider הזה זו קומפוננטת React רגילה - שהיא בעצמה משתמשת ב-useState שדיברנו עליואז כדי לעדכן את ה-Value, אני מעדכן את ה-Value איפה שאני שם את ה-Provider, והוא ירדנדר (Render) את כל תת העץ.הוא עדיין ירנדר אותו - כי ככה זה עובד: כי ברגע שהתרנדר אב-קדמון, הוא מרנדר את כל התת-עץ.אפשר לפתור את זה בדרכים שונות, כמו נגיד עם React.memo שהופך קומפוננטות, שמשווה באופן Shallow את ה-Properties, ומרנדר את זה רק אם הם שווים - אבל זה מעצבן, כי אני עכשיו חייב לעשות את זה, גם יש בזה Overhead . . . יכול להיות שזה לא כזה מעניין, ברוב המקרים, תכל'ס, זה לא מעניין - כי זה לא שווה את ההתעסקות, כי זה לא משנה באמת את חוויית המשתמש, האופטימיזציות האלה.אבל כשיש אפליקציות ענקיות, ש-Rendering הוא מאוד יקר, והדברים האלה מתחילים להציק - אז זה מתחיל להיות בעיה, ואז מתחילים לחשוב מה לעשות.(רן) אבל זה כן משנה את חוויית המפתח, זאת אומרת - או שתצטרך לעשות Props Drilling, או שתצטרך להשתמש ב-Context, שזה - בוא, בינינו - זה משתנה גלובאלי, עם כל המעמסה שבאה עליו.אז כן - למפתח זה אומר איזשהו נטל תחזוקתי(אסף) כן, לגמרי . . . (רן) אז זו הבעיה . . . הבנו - האקדח מהמערכה הראשונה . . . . בסדר.אז Recoil היא זו שתיקנה את הבעיה הזו?(אסף) Recoil תיקנה חלק מהבעיות האלה, כן . . . ב-Recoil, זה התחיל מהרצאה שהייתה ב-ReactEurope, שזו אותו כנס ש-Dan Abramov עשה בו את ההרצאה המפורסמת על Reduxאז זה בחור מ-Facebook, שסיפר שיש להם כלי ב-Facebook, שהם עושים כל מיני סטטיסטיקות על user-ים.הוא סיפר שם על כל מיני דרישות שהיו להם מהמוצר הזה - והוא רצה להשתמש ב-State וב-Context אבל נתקל בכל מיני בעיות - אחת מהבעיות הייתה . . . עוד בעיה שלא הזכרנו בנוגע ל-Context זה שאם אנחנו רוצים שה-User ייצור באופן דינאמי State - בוא נדמיין לדוגמא שזו הדוגמא שהוא מביא - אז לדוגמא, יש לי אפליקציה שאני יכול לצייר בה צורות - אני יכול לצייר בה עיגול, אני יכול לצייר בה מרובע, וה-User יכול פשוט להכניס עוד צורההוא יכול גם לעשות לזה Drag, או לשנות לזה את ה-Size . . . אפשר לדמיין מעיין Photoshop כזה . . . עכשיו - לכל אחד כזה הוא רצה ליצור State משלו - והסיבה שהוא לא רצה את זה ב-State משותף זה בשביל Performance, דיברנו על זהכי אם יש State משותף אז זה ירדנדר את כולם, וכשאתה מתחיל לעשות דברים כמו Dragging, וזה קורה 60 פעמים בשנייה, אז זה כבר מתחיל לכאוב . . . אתה כבר לא יכול, אתה צריך להתחיל לשחק פה עם Performance Optimizations.אבל הוא אמר “אולי נשתמש ב-Context, ועדיין העניין ב-Context הוא שזה סטאטי, ואתה חייב לדעת מראש כמה Context-ים את צריך ליצור . . . אתה לא יכול ליצור Context באופן דינאמי מתוך קוד.וזו בעיה ל-Use Case שכזה . . . זו אחת הבעיות . . . וכמובן יש את כל הבעיות שדיברנו עליהן מקודם.אז מה שהם עשו ב-Recoil . . . הם עשו כמה דברים מאוד מעניינים - אחד - בניגוד לספריות אחרות, ברוב הספריות - זו ספרייה שהיא מאוד Coupled עם React - אתה לא יכול להשתמש ב-Recoil ללא Reactבניגוד, נגיד ל-Redux או ל-MobXויש לזה כמה יתרונות נחמדים, כי ה-API של זה מאוד מאוד פשוט, והוא מאוד דומה ל-API של React, אז במקום useState, אתה תשתמש ב-useRecoilState, וזה יחזיר לך את אותו הדבר - יחזיר לך State ו-setState - וזה מאוד Familiar למי שמכיר את React, אתה לא צריך ללמוד הרבה, בניגוד ל-Redux וגם ל-MobX, שצריך ללמוד דברים.והקונספטים מאוד פשוטים - יש בעצם את ה-State הכי פשוט, שנתנו לזה שם די טוב - קוראים לזה- Atom, כי זה משהו אטומי . . . ובו אתה מגדיר State.עכשיו, אתה מגדיר את זה באופן נפרד, במודול אחר, שהוא לא יושב בתוך הקומפוננטה שלך, ולכן אתה יכול לשתף אותו עם קומפוננטות אחרותפשוט עושים לו Import . . . אתה לא צריך לעשות איזשהו Provider שיושב בעץ-למעלה.כל אחד מהם יכול לעשות לזה Import בנפרד, מבלי שיש את התלות הזאת בעץ.(רן) אוקיי . . . אבל זה דווקא . . . זה לא משהו שיכול לקרות ב-Run-time - ה-Import קורה בזמן הפיתוח, נכון? אתה לא יכול להחליט Ad-hoc ש . . . אתה יודע, בזמן ריצה, לעשות Import למשהו, נכון? זה קצת מזכיר את הבעיה שהייתה עם ה-Context . . . (אסף) נכון - בגלל זה יש משהו אחר שקיים ב-Recoil ונקרא atomFamily - זו “משפחה של אטומים” . . .אתה מגדיר atomFamily, והוא מייצר לך Atom-ים באופן דינאמי . . . אתה נותן לו ID, והוא יביא לך את ה-Atom המתאים ל-ID, וככה אתה יכול, ב-Run-time, בלי לדעת מראש, אתה יכול ליצור עוד ועוד Atom-ים ולשתף אותם.(רן) אז למעשה, הוא נותן ל-JavaScript לפתור את הבעיה . . . הוא אומר “תעשה Import, אני לא רוצה לנהל לך את המצב” - תעשה Import, ואם יש לך State משותף, תעשה לו Import משני קבצים שונים או משני רכיבים שונים - ובכלל שעשית Import לאותו רכיב, אז ה-State ישמר . . . זה הקונספט.אוקיי, JavaScript . . . אני שואל את עצמי האם יש פה סכנה ל-Race Conditions למיניהם . . . אם שני אובייקטים מחזיקים . . . טוב, זה כנראה לא קורה ב-JavaScript כי זה רץ בסביבה נפרדת, אז יש לנו פה Event Loop וזה לא יכול לקרות.(אסף) כן . . . גם בנוסף, בדומה ל-Redux, האובייקטים האלה הם Immutable - הם לא יכולים להשתנות לעולם, מרגע שהם נוצרו.(רן) אז איך אתה מעדכן State, אם זה Immutable?(אסף) אתה יוצר חדש . . . בכל פעם שאתה מעדכן State אתה לא משנה אותו - אתה יוצר אובייקט חדש, למעשה.(יונתן) תזכור ש-State is Evil . . . אז . . .(רן) כן, אבל דיברנו על . . . . אז בוא רגע נחזור לדוגמא שבה יש לנו רשימת To-Dos . . . יש לנו בחלק המרכזי של הדף את הרשימה המלאה עם ה-Check-box-ים לידה, ולמעלה מצד ימין אני רוצה להחזיק רק את מספר האייטמים שעדיין לא סיימתי, אוקיי? אז אני כן רוצה לעדכן פה איזשהו State, נכון? אני רוצה שלשניהם יהיה single source of truth - אבל אתה אומר שזה Immutable, אז מה אני עושה? איך אני מעדכן?(אסף) מעולה, אז בוא נלך על הדוגמא שאמרת - אם אנחנו משתמשים בפתרון שהוא mutable, כמו נגיד -Redux או Recoil, אז יש פה שני דברים - א - יש פה את ה-Counter הזה, של כמה אובייקטים הם Completed - זה מה שנקרא Derived Data: זה Data שאמרנו שאנחנו לא רוצים להחזיק אותו פעמיים, אז אנחנו רוצים לחשב אותו, אנחנו רוצים לחשב אותו מתוך ה-Data האמיתי, שזה ה-Array הזה של ה-To-Do List.גם פה יש עניין של “אנחנו לא רוצים לחשב את זה יותר מדי פעמים, אנחנו רוצים לחשב את זה רק כשדברים ישתנו”, כי זה יקר לחשב דברים, אבל אם נחזור לשאלה הזו, רגע, של “איך אנחנו מעדכנים את זה?”, אז בעצם כדי לעדכן את . . . כדי להוסיף To-Do חדש, אני צריך להוסיף Array חדש, כי אחרת ה-State לא השתנה . . . עכשיו, למה זה חשוב ב-Redux? כי ב-Redux, הוא משתמש בעניין הזה של mutability בשביל ליצור Reactiveness . . . דיברנו על Reactiveness, שזה מתי . . . איך אני יודע שכשה-State משתנה, אני צריך להודיע על הקומפוננטות שמשתמשות בו.אז -Redux משתמש ב-mutability כדי לעשות Shallow comparison - הוא לוקח את ה-Reference של האובייקט, ומשווה את זה - כי זו השוואה מאוד מאוד זולה, זה להשוות שני מספרים - הוא לא צריך לעשות Deep Comparison, ולעבור אובייקט-אובייקט ולראות שזה בדיוק אותו Value, הוא רק משווה את ה-Reference.ולכן, אם אתה עושה את זה Immutable, זה מאוד פשוט ליצור את ה-Reactiveness הזה.כשאתה רוצה לשנות את ה-State, אתה צריך ליצור אובייקט חדש.עכשיו, הדבר הזה הוא נושא ב-Redux, שהוא קצת שנוי במחלוקת . . .כי שוב, דיברנו על Boilerplate - בכל פעם ליצור אובייקט חדש זה יכול להיות מאוד מעצבן, וזה גם יכול ליצור באגים, כי יכול להיות שבטעות שינית את ה-State, כי JavaScript היא שפה שהיא Stateful, אתה יכול לשנות State, הוא נותן לך את זה ואתה יכול לעשות את זה בטעות - ואז זה ייצור באגים, כי בטעות עדכנת את ה-State במקום לעשות State חדש . . . ואז ה-Comparison לא יעבוד, ואז תקבל View שהוא לא Fresh, הוא Stale, וזה לא יעבוד לך ואתה לא תבין למה, ואז אתה תחפש בקוד ועד שתמצא את זה . . . זה נורא מעצבן.(יונתן) זאת אומרת שהייתי יכול לקחת את המערך של ה-To-Dos, ולהוסיף עוד איבר ברשימה - וזה לא היה מרנדר את הקומפוננטות כי React לא היה מודע לזה . . .(אסף) בדיוק, לא היית רואה את זה - והיית שובר את הראש “למה זה קרה לי?”.(רן) דרך אגב, בניגוד למה שאמרת קודם על MobX, שבו אם היית משנה משהו, אז בסופו של דבר כן ה-UI היה עושה לזה רפלקציה (Reflection).(אסף) נכון - ב-MobX, הוא משתמש ב-mutability, והוא בעצם משתמש בהתנהגות הזאת כדי ליצור את ה-Reactiveness.(רן) וב-Redux או ב-Recoil זה למעשה Anti-Pattern - אם אתה מפתח שעובר מ-MobX לאחד מאלה, הולכים להיות לך כמה חודשים קשים בהתחלה . . . (אסף) נכון . . . אבל יש חדשות טובות! אותו בחור שעשה את MobX ואת MobX-State-Tree - הוא עשה גם ספרייה שנקראית Immer, שהיום היא באה בתוך Redux -בגלל ש-Redux . . . אחת מהביקורות הכי גדולות זה כל ה-Boilerplate וכל העבודה שצריך לעשות, Redux עבדו קשה בשביל להוסיף לתוך הספרייה כל מיני כלי-עזר שיעזרו לך עם זה.אחד מהם זה Immer - שמשתמש באותו “קסם” שמשתמשים ב-MobXזה גם אותו בנאדם שהשתמש בקסם הזה ב-MobX . . . כדי לעשות Immutable state - אבל בצורה שנוח יותר לאנשים לעשות את בצורה של mutable . . . מה זה אומר? זה אומר שאתה יכול להשתמש ב-API המוכר של JavaScript, של לעשות State.משהו.משהו = . . . לשנות את האובייקט הקייםבדוגמא שנתנו מקודם - להוסיף איבר למערךאבל מאחורי הקלעים, באמצעות אותם קסמים שדורסים את ההתנהגות של האובייקט, הוא ייצור לך אובייקט חדש, עם רפרנס חדש, וה-Shallow Reference Comparison יעבוד והכל יהיה כיף!אתה לא צריך ליצור Spread . . . מה שקורה הרבה פעמים זה שאתה יוצר Spread-Operator כדי לעשות Spread לאובייקט הקודם מתוך אובייקט חדש - וזה גם, פעם לא היה את זה, זה חדש, קיים רק כמה שנים, פעם היה צריך לעבוד עוד יותר קשה . . . אז זה עושה API ממש ממש כייפיהיום, Redux זו חווייה הרבה יותר כייפית ממה שהיה כשאני השתמשתי בזה . . . כשהתכוננתי לפודקאסט, ראיתי שהם עשו שם המון המון עבודה כדי לטפל בבעיות האלה.(רן) אני כבר מצליח לדמיין את הפרסומות - “להרגיש Stateful ולהיות Stateless!”, אבל טוב . . . [יש מצב . . . פרסומות הרבה פחות מוצלחות מזה כבר רצות היום על איילון]מעולה, מגניב - אז בוא נעשה רגע סיכום: בגדול, דיברנו על מה זה State Management, ולמה בכלל צריך את זה בצד של ה-Clientדיברנו על זה שלוגיקה עברה לצד של ה-Client, ולכן זה . . . הדברים מתחילים להיות מסובכים וצריך איזושהי דרך, ככה “לסדר את הקוד”, זה לא יכול להיות הכל ספגטי - jQuery Spaghetti, למי שיצא התענוג . . .אז קשה מאוד לנהל קוד כזה, ולכן נולדו ספריות של State Managementדיברנו קצת על React, דיברנו על MobX, שיש להן גישות שונות ובסופו של דבר על Recoilאז תודה רבה! כמה מילות סיכום?(אסף) היה לי ממש כיף, אפשר להמשיך לדבר על הנושא הזה עוד המון-המון-המון - זה נושא מאוד Debatable . . . יש המון פתרונות, כל הזמן קמות ספריות חדשות, זהו . . . תודה רבה!תודה לך אסף, ושהיה בהצלחה ב-livecycle. להתראות! האזנה נעימה ותודה רבה לעופר פורר על התמלול!

זהו פרק 413 של רברס עם פלטפורמה, הוקלט ב-8 ביולי 2021, וזה הטייק השני - הטייק הראשון היה מוצלח במיוחד, אבל הוא לא הוקלט . . .אז הנה אתם פה, בטייק 2, יחד איתנו - כן, אני יודע שבשבילכם זה הטייק הראשון, בסדר - אז היום אנחנו נמצאים באולפן שלנו ביוקנעם עילית (!), אורי נמצא בחופש ומחליף את אורי יונתן מ-Outbrain - היי יונתן, מה נשמע?(יונתן) היי, מה העניינים?(רן) מצויין, ברוך הבא - ואיתנו נמצא גם ירון מחברת Soluto - היי ירון!(ירון) היי, מה העניינים? נעים מאוד . . . .(רן) טוב שבאת - היום אנחנו הולכים לדבר על GitOps, בפעם הראשונה.ולפני שנדבר על GitOps, נעשה סבב היכרות קצר - יונתן, היית כאן הרבה פעמים בפודקאסט לפני זה [הקדמה והיכרות - בפרק הקודם], אבל בוא ספר לנו בכל זאת עוד קצת על עצמך - (יונתן) אז אני הגעתי ל-Outbrain לפני 10 שנים, כמהנדס Backend, ובחמש השנים האחרונות אני מנהל את הפיתוח.ומאזין ותיק של רברסים [וגם אורח - 328 The tension between Agility and Ownership או Final Class 23: IDEs או 131 uijet או 088 Final Class 2, וכמובן 412 Serverless at Via](רן) מצויין - טוב שאתה פה.ירון - שני משפטים עליך?(ירון) אז אני ירון עידן, אני מוביל את צוות ה-DevOps ב-Solutoאני משחק עם מחשבים כבר יותר מ-20 שנה - התחלתי בצבא בתור DBA ואחרי זה עברתי להיות מפתח.לפני כמה שנים כבר גיליתי את עולם ה-DevOps ועברתי אליו לחלוטין - ומאז אני מאוד נהנה מהעולם הזה.ב-Soluto אני עושה את זה כבר משהו כמו חמש שנים.אני אספר גם קצת על Soluto, החברה שבה אני עובד - Soluto היא חברה שרוצה להפוך את הטכנולוגיה לדבר יותר ידידותי, בעיקר עבור אנשים שעבורם טכנולוגיה “זו לא השפה הראשונה שלהם”.אז המשתמשים שלנו יכולים לגשת לממשקים ב-Web או ב-Mobile ובעצם לקבל את המיטב מהמנויים הדיגיטליים שלהםלוודא שכל המידע שלהם מאובטח ושמוראם יש להם איזושהי מכונת כביסה חכמה בבית אז הם יכולים לוודא שהמכונה מתפקדת כמו שצריך ושהם מצליחים להשתמש בה . . .ובצד השני - יש להם גם את היכולת לפתוח איזשהו צ'אט, איזשהו Session של Chat עם Expert-ים - וגם הם משתמשים בפלטפורמה שאנחנו מפתחים בתל אביב, שנקראית Anywhere Expert, והיא מאפשרת לתומכים טכניים להיות מסוגלים לעשות את הסשנים האלה מהבית שלהם, מתוך איזושהי אפליקציה, כמו ב-Uberכבר לא צריכים לשבת בתוך איזה Cubical עם אוזניית מדונה ב-Setting קצת אפרורי - אלא ממש להשתחרר ולעשות את זה בתנאים שלהם.זה מייצר Disruption ענק לכל התעשייה הזאת של Tech-support בארה”ב - שם נמצאים רוב הלקוחות שלנו.(רן) אז זה, למעשה, Marketplace של תומכים ונתמכים - מצד אחד יש את הנתמכים, שאלו אנשים שיש להם, לצורך העניין, בעיה עם הטלפון או עם מכונת הכביסה או כל מכשיר אחרומצד שני התומכים, שבזמנם . . . אולי בנוסף על עבודתם, כמו שאמרת כמו ב-Uber, עושים השלמת הכנסה בזמנם החופשי.(ירון) כן - אנחנו אוהבים לחשוב על זה שאנחנו מצליחים לתרום לשני הצדדים הרבה מאודגם לגרום לאנשים להרגיש שהם מוציאים את המיטב ממה שהם שילמו עליו כסףוגם לגרום לאנשים לעשות את העבודה שלהם בתנאים יותר משחררים [אה . . . ](רן) אז הנה שאלה מפתיעה, שהרבה זמן לא שאלו אותך - אמרת שאתה כבר מתכנת הרבה זמן, אז תהיתי מה היה המעבד הראשון שסבל את נחת זרועך?(ירון) אז יש לי Deja Vu . . . אני חושב שזה היה 386 לדעתי? אבל נראה לי שעברתי על כל הסדרה, ואיפשהו בילדות מצאתי מצאתי איזושהי חוברת כזאת בעברית שמלמדת לתכנת ב-Basic, התחלתי לפתוח אותה - ומאז לא הפסקתי.(רן) עדיין ב-Basic?(ירון) התקדמתי מאז - עכשיו אני ב-Pascal . . . [אין יותר טוב מזה](רן) יפה . . . Turbo Pascal [אוקיי, יש יותר טוב…], Object Pascal . . . נחמד - הכחול והתכלת הזה, מקסים, הנדסת אנוש למופת.[אתה לא ציני, נכון? זה היה נפלא]בסדר - אז אנחנו התכנסנו היום כדי לדבר על GitOps.כולם, פחות או יותר, יודעים מה זה Git, וכולם, פחות או יותר, יודעים מה זה Ops - החלק המעניין של DevOps, להזכירכם . . . אבל מה זה GitOps? מה זה השילוב הזה ביניהם?(ירון) אז כן - דבר ראשון, הטרנד היום זה באמת לשים סיומת של Ops על הכל . . . יש DataOps ויש MLOps, אז עכשיו יש גם Buzzword חדש שהוא GitOps.אנחנו ב-Soluto עושים את זה כבר הרבה שנים, בלי לתת לזה את השם הזה, אבל אני כן אתן את ההרחבה של “מה זה בעצם אומר?”אז GitOps היא איזושהי מכניקה של CD, איזושהי אימפלמנטציה (Implementation), שמאפשרת למפתח לדלבר (Deliver) את המוצר שלו ל-Production בצורה שבה Git, או הקוד שיושב בתוך Git, ייצג את המצב של Production.אז אם ב-Continuous Delivery רגיל, יש איזושהו מבוך רציני, שהקוד צריך לעבור מהרגע שהוא Committed ל-Branch הראשי, ועד שבאמת אפשר לראות אותו ב-Production - אז GitOps מנסה לחסל כמה שיותר מהמחסומים האלהובאמצעות איזשהו רכיב שעושה פעולה שנקראת Reconciliation, לבדוק מה המצב של הקוד ב-Git, ולראות האם Production עונה על אותן הגדרות - ואם יש צורך אז לסנכרן בין שני הרכיבים האלה.(רן) כשאתה אומר “מבוך” ,אתה מתייחס, נגיד, לפרישה בהתחלה כ-Canary, ואחר כך אולי פרישה של 25% ב-Data Center אחד ואחר כך ב-Data Center אחר? זה המבוך שאליו אתה מתייחס?(ירון) אז האמת שהמבוך הזה יכול להיות קיים גם ב-GitOps, אבל אנחנו, ספציפית ב-Soluto כן משתמשים ב-Canaryהוא אפילו ניהיה הרבה יותר נגיש עבורנו בזכות השימוש שלנו ב-GitOpsשני הדברים האלו הם לא Mutually-exclusiveהמבוך שאני מתאר זה בעיקר להיכנס לתשתית של ה-CI, ללחוץ על “Deploy”, לראות שמשהו נתקע, להיזכר שהיה צריך לשדרג את ה-Script שעושה את זה . . .(רן) כן . . . בעצם אתה מדבר על ההתערבות האנושית שנדרשת אחרי שהקוד כבר נמצא ב-Master . . .(ירון) נכון - וגם זיהוי של טעויות שמתרחשות בזמן ה-Deployment - נניח, אצלנו ראינו הרבה פעמים שבגלל התאימות היחסית של Pipelines של Deployment, הרבה פעמים יש שגיאה ב-Production, והיא לא משתקפת חזרה ל-Pipeline של ה-Continuous Delivery - ואז המפתח פשוט יושב ואומר “טוב, זה כנראה לוקח לו הרבה זמן . . . זה כנראה הגמדים שלוקחים את הקופסאות ל-AWS התעכבו בדרך . . . “ורק אחרי 20 דקות או 30 דקות יש איזושהי הבנה שמשהו השתבש בצורה נוראית . . . (רן) זאת אומרת - ברגע שאני עושה Merge של Branch ל-Master - אני אף פעם לא אעשה הרי Commit ל-Master, זה אסור . . . - ברגע שאני עושה עושה Merge ל-Master, אני צריך להניח שהכל, כאילו, ב-Production, נכון?(ירון) לאו דווקאיש כלים של GitOps שלוקחים את זה בתור ה-First Class Citizen, הם באמת בונים על זה שתיהיה סדרה של הגנותבין אם זה טסטים ו-Smoke Tests או Canary ו-Gradual releases, כמו שהזכרתוהם פשוט מניחים שהמשתמש עושה בהם שימוש.אנחנו מעדיפים Deployments יותר קונטקסטואליים, ובגלל זה בהתחלה התחלנו להשתמש ב-Flux, שהוא כלי של WeaveWorks שלוקח את המתודלוגיה הזאת קדימה, ומנסה באמת “לאסור על ה-user” ליצור שינויים . . . ליצור הבדלים בין Production לקוד.ועברנו ל-Argo - כלי של Intuit - שחולק איתו הרבה מהקוד, אבל משנה הרבה מהדינמיקה והמכניקה.הוא מאפשר באמת קודם כל להכניס את הקוד לתוך ה-Master - ורק אחר כך להגיד למפתח “תעשה את הסנכרון שלך בצורה מודעת”.יש גם אופציה ליצור Sync אוטומטי, ואז ברגע שההגנות האלו נמצאות ובאמת יש את הבטחון לדעת שמה שנכנס ל-Master יכול להגיע ל-Production, ניתן להדליק את ה-Flag הזה ולהינות מחיים עם הרבה פחות Toil, הרבה פחות עבודה ידנית.(רן) אז דיברת על Reconciliation ועל זה שיש הפרשים בין מה שקיים ב-Master, שאמור לתאר את סביבת ה-Production, לבין סביבת ה-Production האמיתית, וההפרשים האלה יכולים לנבוע מכמה דברים - קוד שנכנס ל-Master, אבל עדיין לא עבר Deployment, אבל זה יכול גם להיות לנבוע מזה שהלך איזשהו איש Ops ושינה את ה-Production . . . נכנס ל-AWS או עשה SSH לאיזשהו שרת ושינה שם משהוואולי יש Drift-ים מכל מיני סוגים, ואני בטוח שכל מי שנמצא בעולם האופרציה נתקל בדברים האלה.אבל איך . . . מתי זה הגיע לנקודה שבה זה ממש הפריע לכם, ואמרתם “עד כאן! פה אנחנו חייבים לקום ולעשות איזשהו מעשה! אצלנו לא יהיה הבדל בין Master ל-Production!” . . . היה איזשהו אירוע מכונן שגרם לכם לעשות את זה?(ירון) אז היה . . . לפני שאני אסביר את האירוע הזה, אני גם אסביר איך הגענו למקום שבו אפשר לחשוב בכלל על הקונספט הזה.כמו שאמרתי - עשינו את זה עוד הרבה לפני שקראו לזה GitOps, והתחלנו במקומות הרבה יותר Low-stakes מסביבת ה-Production, שמגישה תוכן לקרוב למאה מיליון משתמשים היום . . .איפה שהתחלנו זה בתשתית הניטור שלנו - זה היה כבר לפני יותר מחמש שנים.רצינו לעשות דמוקרטיזציה של הניטור, לא רצינו שזה יהיה משהו שמפתח אומר “אני רוצה לנטר בבקשה . . . קח את השליפה הזו ושים אותה בבקשה על הכלי”וכדי שזה יקרה, יצרנו איזשהו Repository, שמנו בו קובץ JSON ענק ואמרנו למפתחים: “פשוט תכתבו פה את כל מה שאתם רוצים לנטר, וזה יגיע “בדרך קסם” אל התשתית”.אז זה היה ה-Production הראשון אצלנו שבעצם כל Commit ל-Master הסתנכרן עם הקוד, והיופי של זה היה שבאמת יכולנו לשחק פה ב-Stakes יותר נמוכים.שבירה של תשתית ניטור זו בעיה מסדר שני - משהו שיכול לקרות לדקה-שתיים בלי שהמשתמשים ירגישוזה בדרך כלל קורה בצורה מבוקרת, כשהמפתחים במשרדולכן זה היה משהו שנתן לנו להתנסות עם זה בצורה בטוחה.(רן) אז למעשה, המוטיבציה הראשונית שלכם הייתה לספק חווייית-מפתח יותר טובה - במקום שהוא ילך ויפנה אליכם ויבקש “תוסיפו לי בבקשה Monitoring” או שבמקום שיצטרך להכיר את כל החוכמות של כלי הניטור, הוא יכול לערוך איזשהו קובץ JSON ולעשות Commit - ומבחינתו זה ממשק העריכה - ועכשיו הוא מבין שברגע שהוא עשה Commit, יש איזשהו Hook שלוקח את הקובץ הזה ועושה לו Apply ל-Production.אז מבחינתך זה איזושהי חוויית מפתח יותר טובה - אבל זה עדיין . . . זאת אומרת, אני לא רואה עדיין איך זה בא ומטפל בתקלות Production . . . (יונתן) לכאורה, יכולת לממש את זה גם, נניח, עם CI/CD רגיל, נכון? בלי “הקונץ” הזה של הסנכרון או לבדוק את הפערים?(ירון) נכון - ואני אפילו אגיד שבאיזשהו שלב עברנו לזה: היה לנו Repository אחד מרכזי ואז הכנסנו איזושהי תשתית “כמו CD”, שלוקחת Commit-ים מ-Repository אחד ומזריקה אותם ל-Repo המרכזי הזה.ושם כבר התחילו להרגיש את החסרונות שאמרתי - הכלי היה נשבר הרבה פעמיםהיו נוצרים מצבים שבהם ה-Pipeline הקלאסי הזה, שמנסה להגיע למקום ה-GitOps-י, נתקע בגלל כל מיני טעיות שלא חזינו מראש, והיה קשה לקבל Visibility על דבר כזה.זה דורש יצירה של המון כלים, רק כדי שהדבר הזה יעבוד בצורה שהיא Flowless.(יונתן) עוד משהו שרציתי לשאול - איך ה-GitOps אל מול Infra-as-a-Code - זה משלים את זה? זה השלב הבא של זה?(ירון) זאת שאלה מעולה, כי באמת הרבה פעמים, את ה-Infra-as-a-Code אנחנו עדיין עושים עם כלים שהם יותר “Push-יים” כאלהאנחנו עבדנו קצת עם Terraform, נטינו יותר לכלי שנקרא Pulumi, שהוא סוג-של-כזה-Wrapper סביב Terraform, עם שפות תכנות יותר נפוצות.ושם מרגישים בדיוק את העניין הזה - שכדי עכשיו לשנות את ה-Infrastructure שלי, אני צריך לעשות Apply . . .ולפני שאני צריך לעשות Apply, אני ארצה לעשות איזשהו Preview, ולהציג אותו למפתחים, כדי שהם יבינו איזה שינוי הולך לקרות.ואז המנגנון הכמעט-אימפרטיבי (Imperative) הזה הוא נורא מורגש - נורא מורגש שהולך להיות איזשהו שינוי, וצריך לעשות איזושהי פעולה כדי שזה יקרה.ואחד הכלים שאנחנו מסתכלים עליהם יותר ויותר נקרא Xstate, וזה כלי שבאמת שם את ה-Infrastructure שרוצים ליצור כ-Custom resources בתוך Cluster של Kubernetes, ואז יש איזשהו Reconciliator, שבמקום לעבור עם ה-API של Kubernetes, הוא עובד עם ה-API של AWS או Azure או GCP - יוצר שם את אובייקטים.וזה שוב - שינוי תפיסה יחסית מאסיבי, כי זה אומר שברגע שמפתח עשה commit ל-Master, אז Xstate תופס אותו ומסנכרן אותו לענן אין איזשהו שלב באמצע של Apply, של Preview . . . כל הדברים האלה חייבים לקרות ב-PR, לפני שהקוד משתנה.(רן) מצד אחד - זה נשמע נורא אלגנטי . . . כאילו פיהם וליבם של Production ו-Master שווים. מגניב, נורא סימטרי כזה, נורא פשוט . . .מצד שני - גם נשמע נורא מסוכן: עשיתי Commit . . . סליחה - עשיתי Merge ל-Master, לא עשיתי Commit ל-Master. . . עשיתי Merge ל-Master, ואולי אני לא כל כך יודע מה זה הולך לייצר, זאת אומרת - אני לא יודע שזה עכשיו אולי הולך לייצר בלגאן לא נורמלי בתוך Production. . . אין לי איזשהו מקום קטן שבו אני יכול ככה להתנסות, בקטנה, לפני שאני עושה את ה-Commit? איך מטפלים? איך עושים מיטיגציה (Mitigation) למוטת הכנף הענקית שפתאום כל אחד מקבל?(ירון) זו שאלה נהדרת, כי היא מחזירה לשאלה הקודמת ששאלת - של בעצם “איזו בעיה ניסינו לפתור?”כי דווקא בניגוד או בהיפוך כזה של התמונה הזאת, החוסר ביטחון הגיע לפני שהיה לנו את ה-GitOpsהייתה לנו בעיה שהתשתית… פשוט כשעובדים עם תשתיות כמו Kubernetes אז התשתית נהיית מאוד מאוד מורכבתהיא גם נהיית במצב שכדי להרים Cluster חדש, במקרה של איזושהי בעית Production, בנאדם צריך לעשות פעולה ידנית, שיכול להיות שיכולה לארוך כמה שעות - וזה היה מצב מאוד לא נוח.קשה היה לדעת, כשיש לי מספר מוגבל של Cluster-ים - במקרה שלנו שניים - ואם עכשיו אחד מהם נופל אז אני צריך להיכנס למרוץ נגד השעון כדי ש-Cluster חדש יעלה.וזה גם עיכב אותנו מלייצר, אולי, את מה שרמזת אליו - שזה איזשהו מקום, איזשהו “מגרש משחקים” או ארגז חול בצד, שבו אפשר לעשות את כל השינויים בצורה בטוחה, ולדעת שלא משנה מה אני אשבור - Production לא ידע מזה.וזאת בעיה אחת שבאמת נאבקנו בה הרבה לפני שהגענו לעולם ה-GitOps המובטח.בעיה נוספת, שגם אותה אני אסביר איך GitOps פתר עבורנו, זה הארגונומיה של המפתחים מול Kubernetesכי מפתחים אצלנו היו רגילים לעבוד מול אילו-שהם Self-contained Services, שרצים על PaaS, כמו Herokuבמקרה שלנו זה היה Azure, אבל זו הייתה איזושהי סביבה סגורה, מכונות וירטואליות שכל מפתח קיבל, שמריצות את ה-Services שלו.ופתאום לעבור ל-Cluster שהוא Multi-tenant, שכולם עובדים ביחד, שצריך לדעת לא “לדרוך אחד לשני על הבהונות” . . . שיש בהם הרבה-הרבה אובייקטים חדשים שהמפתחים לא מכירים - יצר שינוי פרספקטיבה, שלא היה קל להנחיל לצוותי הפיתוח.אנחנו בצוות עבדנו עם Kubernetes הרבה, אבל המפתחים לא תמיד רצו להבין את המורכבות הזאת, והיה קשה לחשוף אותם לזה בצורה שתפגע איפשהו באיזון הזה . . .(רן) אז גם בהקשר הזה, זה נשמע כאילו אתה בעצם מייצר ממשק למפתחים עבור Kubernetes . . . זאת אומרת: “אתם לא צריכים ללכת ולהשתמש ב-Kubectl או בכלים אחרים” אלא אתם צריכים, לצורך העניין, “לעשות Commit לאיזשהו קובץ JSON ומשם אנחנו כבר נטפל בזה”.(ירון) נכון . . . אז היום הכל YAML, אבל כן - זה השינוי המרכזי שעשינו . . .(רן) . . . השתדרגנו . . . (ירון) . . . עכשיו יש מקפים במקום סוגריים מסולסלים . . .(יונתן) תזהיר את אבישי - יש לו איזה משהו נגד YAML-ים . . (רן) מאזיננו אבישי - תסתום רגע את האוזניים . . . כל העולם YAML כבר, אין מה לעשות . . .(ירון) בהרבה מקומות ראיתי שכבר מגייסים מפתחי YAML . . . (רן) כן - אולי המפתחי XML בפנסיה יהפכו למפתחי YAML . . . נחזור רגע אחורה - דיברת קודם על המוצר שלכם, ואמרת שהמוצר הזה יודע לתת תמיכה למכונות כביסה למחשבים אישיים וכו'. אז כל פעם שאני עושה Commit ל-Master, נגיד לאפלקיציה ה . . .(יונתן) אתה לא עושה Commit ל-Master, רן . . . . תזכור - עוד פעם, אני אעשה לך Reject . . . (רן) איך נפלתי . . . זה הפרוידיאני בי שמדבר . . . אז כל פעם שאני עושה Commit ל-Branch, ו-Merge ל-Master, אחרי Code review, כמובן, ומתקן את כל ההערות, ועובר CI - אז לאפליקציה האחרונה המגניבה שכתבתי למכונת הכביסה של סבתי - אז זה מיד הולך לכל מכונות הכביסה בעולם? לכל הטלפונים בעולם? זאת אומרת - זה באמת מה שאנחנו רוצים?(ירון) אז התשובה היא “לא” . . . כמו שאמרתי, יש לנו מידה מאוד חזקה של Control, כי ככה רצינו לבצע את השינוי הזהלא רצינו להפחיד אנשים ולהגיד לכל מי שעובד על הקוד אצלנו “תזהרו מאוד מה-Master!”הרעיון היה באמת לאפשר לאנשים יותר Visibility, יותר שקיפות - ולאט-לאט להגיע למודל הבגרות הזה, שבו אנחנו מרגישים בנוח לסנכרן דברים בצורה אוטומטית.זה אומר שהיום, רב שירותי ה-Backend שלנו נפרשים באמצעות כלי GitOpsבאמצעות Argo, שציינתי קודםמה שהמפתחים מקבלים מזה זה להחליף את ה-Pipeline המסועף והקשה להבנה באיזשהו Commit ל-Masterעכשיו, במקום לעשות את ה-Deployment בשלב הזה של ה-Pipeline, יש רק Commit אחד, שמשנה את ה-Version ש-Argo מסתכל עליו.ברגע שנעשה שינוי ה-Version הזה, המפתח הולך ל-UI אחר, של Argo - הוא רואה בצורה מאוד מאוד ברורה שהשתנה שדה מסויים ב-YAML של ה-Deployment שלו, עם ה-Tag.וזה מייצר הרבה דברים מאוד טובים עבורנו - כי גם אם עכשיו מבצעים סנכרון של הדבר הזה, אז זה כבר לא איזשהו Context-switch של לעבור עכשיו ולהסתכל מה המצב - Argo ממש מראה יפה, עם לבבות ירוקים או לבבות אדומים-שבורים , מה הסטטוס של הגרסא הישנה והגרסא החדשה.וזה נותן פידבק מאוד מהיר - האם השינוי הזה כרגע עובד? האם השינוי הזה נכשל? האם צריך לחזור רגע לשולחן השרטוטים ולתקן אותו?במצב הנוכחי, זה דווקא הגביר מאוד את ה-Control ואת השליטה שלנו ב-Production, ולא יצר אי-יציבות וחסר ודאות.(יונתן) ה-State הזה, נניח של שינוי הגרסא - נניח שאני מהנדס, ויש לי גרסא חדשה - אתה אומר, בעצם, שדבר ראשון אני צריך לעשות Branch ו-Commit ו-Merge, בגלל שאני רוצה גרסא חדשה, עם איזשהו Tag - זה ב-Repository של האפליקציה שלי או שזה ב-Repository של האפליקציה שמנהלת את ה-GitOps?(ירון) זו שאלה נהדרת, כי באמת אנחנו עושים משהו לא מסורתי שם - אנחנו כן עושים את כל השינויים האלו ב-Repository של הקוד, ובדרך כלל - אני מקשיב בכנסים, קראתי פוסט יפה של מישהי מ-Riskified שכותבת איך הם עובדים עם Argo - וראיתי שהקונצנזוס, פחות או יותר, הוא להפריד את ה-Repository שהמכונות קוראות וה-Repository שבני האדם קוראים . . . אז בדרך כלל, מה שמקובל זה ליצור, נגיד, את “Yaron-API”, להגיד שזה הולך להיות ה-Service שלי, ופה אני, כבן אדם, כותב קוד - ואז לתת למכונה לעשות את ה-Commit לאיזשהו Repository אחר, שיקרה “Yaron-API-Deployment”, ומשם לקחת את ה-State שה-Argo מסתכל עליו.אנחנו, פשוט בגלל שרצינו את הנושא הזה שאמרתי קודם - רצינו לשפר ארגונומיה של מפתחים - לא רצינו שיהיה להם את ה-Context-Switch הזה, את המעבר כל הזמן בין ה-Repo שבו הקוד כתוב לבין ה-Repo שבו ה-Deployment קורה . . .(יונתן) גם יש עוד יתרון - אתה תעשה git-log ותראה את ה-Deployments ולא . . . הרבה אנשים אומרים הפוך . . . הם אומרים “אני לא רוצה לראות Commit-ים של מכונה” [אחלה שם לפודקאסט, אגב], זה לא קדוש.אבל אנחנו מאמינים שה-Commit-ים האלה באמת, כמו שאתה אומר, מייצגים את השינוי של ה-State.(רן) אני מניח שהויכוח הזה, או הדילמה הזו, במצב של Mono-Repo היא פחות רלוונטית - עדיין יש התלבטות, נניח שאנחנו בעולם של Mono-Repo, ואני מבין שאתם לא - יש את ההתלבטות של האם לשים את הקונפיגורציה קרוב לקוד, או את כל הקונפיגורציה במקום אחד, לצורך העניין באיזשהו Branch או תת-עץ של ה-Mono-Repo.גם אני הייתי בהתלבטות הזאת הרבה פעמים, ואני חושב שיש פה Trade-off - מצד אחד זה נחמד שהקונפיגורציה קרובה לקוד, ולפעמים ממש בתוך הקוד; ומצד שני, זה גם נחמד לקבל איזשהו מבט על כל הקונפיגורציה של כל ה-Service-ים השונים, וככה להבין איך הדברים קורים.אז אני מבין שאתם יותר נוטים לשים את הקונפיגורציה קרוב לקוד, אם אפשר לקרוא לזה “קונפיגורציה”, בוא נקרא לזה . . .?(ירון) אז גם פה יש כמה תשובות . . . דבר ראשון - אנחנו לא נגד Mono-Repo, אנחנו מאוד-מאוד בגישה של “לתת למפתחים ולמפתחות פשוט להחליט מה הכי טוב ב-Context של המשימה הנוכחית” ולכן יש אצלנו קבוצה שלמה שעובדת בתוך Mono-Repo אחד, שמחזיק את כל ה-Service-ים, בלי שום קונטקסטויש לנו קבוצה שעובדת עם Repo-per-Serviceויש קבוצה שלישית, שעובדת עם Mono-Repos קונטקסטואליים . . . (יונתן) אתם לא נגד Mono-Repo - פשוט יש לכם הרבה כאלה, זה מה שאתה אומר . . . [“רבים מידידי הטובים ביותר” וכו'…](ירון) בדיוק . . . אנחנו אוליגו-Repo . . .(רן) לא, יש לזה גם שם - Multi-Mono-Repo . . . כתבו את זה לפנינו . . .(ירון) כן . . . אז לא הגענו למצב שבאמת אנחנו יכולים להגיע לרמות של Facebook, והקסמים שהם עשו עם Mono-Repos שם.בסוף, Mono-Repo ענק שמחזיק את כל הקוד זו לדעתי משימה הנדסית כבירה, וצריך לעשות אותה בצורה מאוד מחושבת.ושוב - בגלל הצורה ה-Distributed והלא-פרספקטיבית שאנחנו עובדים בה, שאנחנו לא רוצים להגיד לאנשים איך לעבוד, אז כמעט בלתי אפשרי לחשוב על “כל המפתחים ב-Soluto כותבים ל-Repository אחד”,כי דברים קמים, אנשים רוצים לשנות דברים, להתנסות עם משהו חדשוברגע שאנחנו מאפשרים את זה, אז לא נקבל אף פעם את השליטה של להגיד לאנשים “כל ה-Commit-ים שלכם עכשיו יהיו רק ב-Soluto-Code” [וגם אז - רק אם הם טובים]וזה נחמד, כי זה כן גורם לנו להתקדם קדימה . . .(רן) כן . . . אני חייב להעיר שאם כל זה שאני מכבד את שיקול דעתם של המפתחים, ואני הרבה פעמים גם לא רוצה להגיד למפתחים אחרים מה לעשות - אני חייב להגיד שלפעמים יש הרבה חוכמה בכן להגיד למפתחים מה לעשות, כי אני חושב שהרבה פעמים ההחלטות הן שרירותיות, והחלטה אחת טובה כהחלטה אחרת - הבעיה שכששתי החלטות, ששתיהן שקולות, אבל כששתי החלטות נלקחות, אז אתה בבלגן . . . אז דווקא בקטע הזה אני נוטה להיות קצת יותר הדוק, ולבוא ולהגיד “חבר'ה, נכון - יש פה שתי דעות, אבל אני בוחר את זאת, “כי ככה” - ובואו נתגלגל עם זה הלאה”כי אחרת פשוט נוצר בלגאן - וראיתי את זה קורה בחברות גדולות . . . ראיתי את זה קורה ב-Google,אני מבין ממה שאתה אומר שזה קורה גם ב-Facebook . . . מתקבלות החלטות שרירותיות, וכל המפתחים לפעמים אולי מקטרים - אבל הולכים לפיהןוזה עושה הרבה טוב, בסופו של דבר - “המסר שלי לאומה” הוא של “לא לפחד לקבל החלטות בשביל המפתחים”, ובסופו של דבר, בשורה התחתונה, אני חושב שזה עושה טובה, כי זה יותר קל כשדברים הם אחידים.(ירון) זה מעניין מאוד - ואני חושב שמה שאתה מציין הוא גם פונקציה של גדילה.אני חושב שיש שלב מסויים שבו חברה יכולה להרשות לעצמה להתפזר יותר ולנסות יותר דברים, ויש שלב מסויים שבו צריך להתכנס ולהגיד “אוקיי, ה-Business הגיע ל-SLA מאוד גבוה שהוא צריך לספק, החברה גדולה מספיק כדי שלא נוכל לתת ל-15 Frankenstein-ים לרוץ במקביל, המפלצות של . . .(רן) כל מפלצת טובה . . . כל מפלצת לכשלעצמה היא בסדר . . . אני לא אומר שההחלטות הן לא נכונות, הבעיה שיש החלטות אחרות, והחלטות סותרות לפעמים, החלטות שלא עובדות טוב אחת עם השנייהאו אפילו אם לא סותרות - לייצר Infrastructure שמתאים גם . . . לצורך העניין אפשר לקחת שפות תכנות - Infrastructure שמתאים גם ל-Python וגם ל-Ruby וגם ל-Java זה אפשרי, אני בטוח שזה אפשרי - זה רק יותר קשה.אז אתה יודע - שפות תכנות אפשר בדרך כלל, רוב החברות מתקבעות, זו לא הבעיה - אבל עדיין יש עוד הרבה בחירות אחרות:איך עושים Messaging, איך שומרים, באיזה Database משתמשים וכו'.(יונתן) אני חושב שאני מסכים - מבחינתי, המדד של מתי צריך לקחת כזאת החלטה או “דיקטטורה נאורה” שכזאת זה כשאתה צריך “לעבוד לרוחב”דיברת על תשתיות - ברגע שאתה צריך להתחיל . . . כשתשתיות נהייה “עניין”, אז קשה לתמוך בוריאנטים השונים . . . [כן . . .](רן) בוא נחזור רגע אחורה ל-GitOps . . . אז נלך, שנייה, Back-to-Basics: הבנו את הקונספט של “Mater ו-Production צריכים להיות שווים”. אז אני, אתה יודע, מתחיל ככה ב-Back-to-Basics ואני רוצה לעשות GitOps, אוקיי? אז מה אני עושה? אני מייצר Git-Hook, ובעצם אני צריך לדאוג לשני דברים . . .אחד זה שיהיה לי קוד שיודע לתאר את סביבת ה-Production, נגיד - כמה Server-ים, כמה Services, מה ה-Multiplicity שלהם, כל מיני דברים . . . מה שיודע. . . לצורך העניין קובץ YAML שיודע לתאר את סביבת ה-Production, ובטח יש שפות למכביר שיודעות לעשות את זה.אז אני צריך קוד שיודע לתאר את סביבת ה-Productionושתיים - אני צריך לדעת לעשות איזשהו Git-Hook, נגיד, שכל פעם שעושים Commit אז Production מתעדכן לפי מה השינוי האחרון.אז זה אולי GitOps בממש-ככה-30,000 רגל - ואתה הזכרת שיש כמה כלים שיודעים לעשות את זה - הזכרת קודם את Flux של WeaveWorks והזכרת את Argo של Intuit - ואני מניח שיש עוד כלים אחרים בשכונה.אז אם קם הבנאדם בבוקר ואומר “יאללה - בא לי GitOps!” [חמור מאוד] או “אני חייב GitOps!” [תופעת לוואי חדשה?] או “המנהלים שלי אומרים לי שאני צריך GitOps . . . “ [המקרה היותר נפוץ?] - איך אתה ממליץ לו להתחיל?(ירון) אז אני אזכיר פה את Kelsey Hightower, שהוא מן בחור כזה שאוהב לדבר על Kubernetes, מ-Google [בדיוק זז שם קצת], ואני מאוד אוהב גם את הצורה שבה הוא מנגיש ידע מורכבנגיד, לפני הרבה שנים הוא כתב את Kubernetes-the-hard-way [אבל כבר קישרתי לזה…], שזה מעיין מדריך על איך להרים את Kubernetes מ-Scratch, לעשות את כל הפעולות שעשויות, עבורנו, בצורה ידנית - וכשעברתי דרכו הרגשתי היכרות הרבה יותר טובה עם התשתית הזו, שהיום מעירה אותי בלילה אם יש לה בעיה . . .והוא עושה הרצאה מדהימה - יש כבר כנסים שנקראים GitOps Days מרוב שהדבר הזה טרנדי - הוא עשה הרצאה ממש מעניינת בכנס שהיה בשנה שעברה, שבה הוא מראה איך עושים Reconciliation Loop מ-Scratch . . . הוא ממש כזה . . . מראים קוד שהוא כותב ב-Go תוך כדי על המסך, תוך כדי הכנס - והדבר הזה מייצר, במקרה שלו, פונקציות של Cloud Run, שזה איזשהו Serverless כזה של Google.אני חושב שההרצאה הזאת היא פתיח מדהים בשביל לעשות דימיסטיפיקציה (Demystify) למשהו שבאמת, כמו שאמרת, יכול להישמע מורכב ויכול להישמע אפילו די מפחיד, כי זה מראה שהדבר הזה יכול להיות מאוד נשלט.אחרי שעוברים את המשוכה הזאת, של להבין את הקונספט, הייתי כן ממליץ לבחור את אחד מהכלים הגדולים - בין אם זה Argo או Flux, כי הם כרגע הכלים ששולטים בשוקאבל גם חשוב מאוד, כנראה, להבין את הבעיה - אם Argo ו-Flux מתאימים מאוד לתחזוקה של Kubernetes, אז אם רוצים לתחזק משהו שהוא מחוץ ל-Kubernetes, צריך לבחור משהו שהוא כלי שיודע לעשות את זה גם בלי הכוח הזה.וכמו שאמרתי - גם Puppet ו-Chef יודעים לעשות את זה עבור מכונות Linux, ויש כלי שנקרא Atlantis, שיודע לעשות את זה עבור Terraformואז בעצם כל אחד מהכלים האלה יכול להיות Entry-point ל-GitOps, לא משנה מה האתגר שכרגע עומד מולכם.(רן) נזכיר, אני חושב ששווה אולי לבוא ולמצוא את המקבילות בין הכלים השונים - אז גם מי שמכיר את Puppet ואת Chef - הם כולם עובדים באיזשהו Mode של Reconciliation Loopזאת אומרת - מסתכלים מה המצב הרצוי ועושים Apply, וכל פעם עושים Reconciliationזאת אומרת שאם משהו שהגדרת, לצורך העניין, שצריך להיות קובץ במערכת על מחשב והוא לא שם - אז הוא בכל פעם ייצר אותו מחדש אם הוא ימחק.גם Puppet וגם Chef עובדים באותה צורה - וגם Kubernetes הרבה פעמים עובד באותה צורה, זאת אומרת שגם ל Kubernetes יש Reconciliation Loop שמסתכל על ה-Resource-ים ועושה Apply ל-Resource מחדש בכל פעם שצריךכמובן שלא סתם . . . אז בהקשר הזה, המוטיב הזה של ה-Reconciliation Loop עובר, כנראה, בהרבה מאוד מהכלים שהזכרת.(יונתן) לפי מה שירון . . . לפי מה שתיארת, יש יכולת גם לעדכון מהצד השני - יכול להיות שזה לא שב-Production, לא רק שחסר קובץ, אלא שמישהו, לא יודע, שינה אותו, או שמישהו נכנס ל-UI של ה- Management של Kubernetes ושינה את ה-State Loader - איך ה-Flow המרכזי . . . מה יקרה אז?(ירון) זה בעיני הדבר . . . זה ממש ה-Added-Value, אולי אפילו ה-Killer-Feature של GitOps, כי אלו הפתעות שתמיד היו תופסות אותנו במקום הכי לא מוכן, ואני מאמין שזה קרה להרבה צוותי Production [מה?! מה פתאום?]שפשוט איזשהו שינוי נעשה בזמן של מקרה חירום, או אולי כלאחר-יד מתוך איזשהו חוסר הבנה, ולא הייתה לדבר הזה שום נוטיפיקציה (Notification)ואז בדרך כלל מגלים את זה חודשים, אם לא שנים, אחר כך, כשהידע כבר נשכח . . . יש את הפתגם הזה - שקוד שכתבת אחרי חצי שנה הוא כמו קוד שנכתב על ידי מישהו אחר [יש לזה אפילו שם - Eagleson's law] . . . אז גם עבור שינויים ב-Production הדבר הזה תקף - מה גם שהם הרבה פחות מתועדים . . .ב-GitOps, בצורה שאנחנו עובדים, Argo מחובר ל-Slack - וכל פעם שמישהו עושה Deployment יש הודעה חמודה כזו עם שאומרת “הקוד שלך שינה בהצלחה את ה-Production”אם במקרה, נגיד, הקוד שלי מסתמך על איזשהו Redis חיצוני, וה-Redis הזה פתאום נפל, אז אני אקבל “לב שבור ועצוב ” שאומר לי “רוץ מהר! משהו השתנה, זה כבר לא נראה כמו ה-Production, אני שבור וקשה לי” . . . (יונתן) אוקיי . . .(רן) מה ה-Hack החביב עליך? נגיד, מסוג הדברים שהתעוררת בשתיים-שלוש בלילה, וגילית “מי לעזאזל עשה את זה?!”? . . . אני אתחיל עם שלי - נניח שאתה נכנס ואתה מגלה שמישהו, לפני חצי שנה, כמו שאתה אומר, ערך את קובץ ה-Host והוסיף שם איזשהו Entry, כי כנראה פעם זה תיקן לו איזשהו משהו . . . עכשיו את מגלה ש Name Resolution מחוץ ל-Host עובד שונה לחלוטין ממה ש-Name Resolution עושה בתוך ה-Host - וזה מסביר הרבה דברים, בדרך כלל . . . (יונתן) סתם, פתאום התחלתי לחשוב האם זה יכול לעזור באילו-שהן בעיות של Security? או של מישהו ששינה משהו עקיף ב-Production, והוא לא עשה Git-Merge וכל הסיפור הזה . . . .(ירון) אז בהחלט . . . אני רק אגיד על ה-Hack-ים - שזה תמיד יהיה נס, אין ספק . . .ה-Hack החביב עלי זה שכשעובדים ב-High Availability, שולחים גרסא אחת של Production ל-Site אחד וגרסא שנייה ל-Site אחר - ועכשיו לך תבין למה חצי מה-Traffic מחזיר תשובה אחת וחצי מחזיר משהו אחר . . .(רן) יש את הסיפור המפורסם על ה-Trading. . . (ירון) כן, Knight - מסכנים . . .(רן) . . . שהם עדכנו גרסא, אבל כנראה נשאר שרת אחד או שניים, שאולי היו Offline בזמן עדכון הגרסא - וזה גרם לחברה לפשוט את הרגל, חברה של שווי, בגדול, של מיליארד דולר, שהפסידו ב-Algo-Trading את כל הכסף שלהם בגלל איזה Deployment שלא עלה נכון . . .(ירון) כן, זה סיפור נורא כשקוראים אותו, ופרקי הידיים מלבינים כי אתה חושב שאולי זה קורה לך עכשיו . . . (רן) ממש עכשיו . . . אבל ממש ממש עכשיו . . .(יונתן) . . תן לי רגע רק לבדוק את ה-Inspection . . .אז בנוגע ל-Security - יש כאן באמת יתרון אדיר, כי גם - ב-Continuous Delivery מסורתי, אני חייב לתת לתשתית שלי את היכולת לגשת ל-Production, ונגיד, אם זה Jenkins שיושב אצלך בשרת, אז לא אכפת לך כנראה לשים שם איזושהי גישת-כתיבה ל-Productionאנחנו עובדים עם SaaS, עם codefresh - חברה ישראלית שעושה CI ממש נחמד לדברים שהם Docker ו-Kubernetesועדיין, עם כל האהבה והרצון הטוב - אנחנו מעדיפים שהם לא יוכלו לגשת ל-Production . . . ברגע שאנחנו עושים את ההפרדה הזאת, הם יכולים לגשת רק עד הקוד - והמוצר היחיד שיכול לגשת ל-Production הוא ה-Reconciler של GitOps, שבמקרה שלנו זה שרת של Argo שיושב על ה-Clusterואז ה-Attack surface הוא הרבה יותר נמוך - כי הוא מלכתחילה יושב שם ומלכתחילה עושה שינויים, וזה טבעי שאצלו ישבו המפתחות [חביתוש?].ואני אעשה גם איזה Shout-out לפרויקט Open-Source שכתבנו ב-Soluto ושנקרא kamus - והוא גם מתבסס על GitOpsהרעיון שעשינו שם הוא שהראינו שה-Secret-ים ב-Kubernetes הם עוד לא בשלים, פחות או יותר - Secrets ב-Kubernetes הוא פשוט איזשהו אובייקט מקודד ב-Base 64, וזה אומר שכל מי שניגש ל-UI ב-Kubernetes ולוחץ על הכפתור של העין פשוט רואה את ה-Secret, פשוט רואה את ה-Plain-text, ולא הרגשנו עם זה בנוח . . .אז כתבנו Controller, שאפשר להתקין על כל Cluster, ומה שה-Controller הזה עושה הוא לאפשר למפתחים להצפין את הערכים מקומית אצלם על המחשב, לעשות להם Commit ל-Gitואז לכל Container נוסף איזשהו Init-Container, שעושה Encryption על ה-Cluster.זה גם מאוד מחזק את ה-Security, כי ה-Decryption יכול לקרות מעכשיו רק בסביבת ה-Productionזה דומה, נגיד, ל-Vault, אבל מגיע עם Operation overhead הרבה יותר נמוך.(רן) הזכרת מקודם - ואולי בזה, ככה, נסיים את הערב - הזכרת מקודם שעם המעבר ל-Kubernetes, מפתחים הרגישו איזושהי עלייה ברמת המורכבות, שהם פתאום צריכים להבין יותר Production, ואז יצרתם ממשק משתמש, או לפחות אני תיארתי את זה ככה - יצרתם ממשק משתמש, ממשק מפתח, באמצעות GitOps.האבחנה שרציתי להגיד זהש-Kubernetes מאפשר GitOps, נכון? אולי זה לא הכלי היחיד שמאפשר GitOps, אבל בהחלט אחד הכלים שמאפשרים GitOps.כי הוא נותן לך לתאר את סביבת ה-Production ולעשות לה Apply יחסית בקלותאז Kubernetes אמנם מאפשר GitOpsמצד שני, לפני Kubernetes אולי לא היה צריך GitOps, כי הדברים היו יותר פשוטים . . .אז אני סתם תוהה האם זו אבחנה שנראית לך מוצדקת, נכונה?(ירון) אני חושב שכולם מכירים את ה-Death-Star של Netflix, שמראה פשוט מיליארד שירותי microService שמדברים אחד עם השניוהם כתבו את Spinnaker, שזה כלי שהוא מזכיר . . . הוא מאוד מאפשר את הסיבוכיות שיכולה להגיע בדברים של Continuous Deliveryעם כל היופי והאלגנטיות של הכלי הזה, אני חושב שהוא בא לשרת משהו שאם לא צריך אותו, אז זה יהיה נחמד להיפטר ממנו.ושוב אני אצטט את Kelsey Hightower שאומר שהקסם והחידוש ב-Kubernetes זה שהתשתית מתוארת כדאטה, לא כקונפיגורציה (Configuration)זו לא סדרה ל צעדים אימפרטיביים (Imperative) שדרושים כדי שמכונת Linux תוכל להגיש קוד ב-Ruby - זה תמיד יהיה דאטה - זה תמיד יהיה קבצים ב-YAML שנשמרים ב-Database, והם אלה שמאפשרים את העלייה של Production.(רן) כן - וזה אולי אחד מהדברים שמאפשרים לעשות GitOps בצורה יחסית פשוטה, כי כל מה שצריך לעשות זה Commit לקובץ YAML - ולעשות Apply . . .(ירון) בהחלט(רן) טוב - אז תודה רבה, ירון, היה סופר-סופר מרתק. יש משהו שהיית רוצה עוד להגיד לפני שנסיים?(ירון) אז אני אשמח להגיד שאנחנו מגייסים - גם לצוות שלי וגם למגוון תפקידים ב-Solutoאם כל מה ששמעתם פה נשמע לכם מעניין, מבחינת החזון של החברה או מבחינת הדברים היותר Geek-יים - בואו, תתראיינו, תתקבלו . . . (רן) מעולה . . .(יונתן) אה, אפשר למסור ד”ש, רן?(רן) קדימה, נו . . . עם איזה שיר? רגע, שאני אכין את התקליטייה . . .(יונתן) שנכין בתקליטייה . . . אז למאזין אורי להב, ששט לו בדוגית בחופי הים התיכון . . . (רן) אורי - מתגעגעים אליך, חזור הביתה!טוב - אז תודה רבה לשניכם, ויאללה, נשתמע . . . להתראות.ובהצלחה ל-Reversim Summit 2021 . . . הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

אדם פישר, שותף בכיר בקרן בסמר ונצ׳ר פרטנר (Bessemer), אחת מקרנות ההון סיכון הגדולות והמצליחות בעולם, אחראי על השקעות הקרן בישראל ובאירופה ונחשב לאחד השחקנים היצירתיים ביותר בשוק ההון סיכון בישראל. פישר יזם בין היתר את ההשקעות בחברות וויקס (Wix), אלוט (Allot), סטורוייז (Storewize) שנמכרה ל־IBM, אינטוסל (Intucell) שנמכרה לסיסקו, סולוטו (Soluto) שנמכרה ל־Asurion, ואקסיס נטוורק (Axis). אדם פישר מדבר עם איל ויצמן על הדרך לצמרת והתבססות בה, על עליה לישראל, על סקרנות, סובלנות והומניות, על ניהול השקעות של מאות מיליוני דולרים בסטרטאפים ובחברות ישראליות, על ההשפעה של חוסר מזל, על הצלחה ועל אקזיטים.

“You don’t need a paper LLC, you need a performing LLC.” -Soluto Uba This week I have Soluto Uba on the show to talk about LLCs and Trademarks, and boy does he deliver! We cover so much legal goodness in this one. You’re gonna wanna definitely take notes: Business formation and LLCs A paper LLC vs a performing LLC A powerful internal document you need to have in place Corporate formalities Trademarks vs Copyrights When to trademark Understanding if you need a DBA Business write offs And so much more! This really is one you don’t want to miss if you want to set a strong foundation as you launch or grow your brand. As always, shoot me a DM if you have any follow up questions! Links mentioned in this episode: The Uba Law Group Website Tax Savings Masterclass Business Launch Blueprint course Facebook: The Uba Law Group Instagram: The Entrepreneur Lawyer YouTube: The Entrepreneur Lawyer Tick Tock: The Entrepreneur Lawyer Also, make sure to subscribe to Bird Means Business so you don't miss an episode! For more episodes, visit: www.birdwilliams.com/podcast

LLC does not neccessarily protect your company name from being used by other people. Findout why in this episode with Uba. We will discuss what's best to obtain, an LLC, Inc or Trademark and why it's important to adjust your finances prior to creating your business. --- Support this podcast: https://anchor.fm/entrepaidneur/support

See omnystudio.com/listener for privacy information.

Ha llegado como cada jueves el Pódcast de Motorpasión México. En esta ocasión te contamos todos los detalles del nuevo Toyota Supra que por fin llega a México. También hablamos de un nuevo modelo de KIA para mercados en desarrollo y del bestial Audi RS6 Avant, entre otros temas. ¡Disfruta!

There are a lot of choices for managing and encrypting secrets in Kubernetes. Kamus is one of those solutions, and it was developed as an open-source project by Omer Levi Hevroni. Today we’re talking with Omer, a DevSecOps engineer with Soluto at Asurion, about his work on Kamus, its origins, and how it’s being applied for secrets management in Kubernetes.

K8s security with Omer Levi Hevroni (@omerlh)   service tickets - Super-Dev   Omer’s requirements for storing secrets:   Gitops enabled Kubernetes Native Secure     “One-way encryption”   Omer’s slides and youtube video: https://www.slideshare.net/SolutoTLV/can-kubernetes-keep-a-secret https://www.youtube.com/watch?v=FoM3u8G99pc&&index=14&t=0s   We’ve all experienced it: you’re working on a task, adding some code, and then you need to store some sensitive configuration value. It could be an API key, client secret or an encryption key ― something that’s highly sensitive and must be kept secret. And this is where things get messy. Usually, secret storage is highly coupled with how the code is deployed, and different platforms have different solutions. Kubernetes has a promise to simplify this process by using the native secret object, which, as the name implies, can be used to store secrets or sensitive configurations. Unfortunately, Kubernetes secrets are fundamentally broken, and a developer who tries to use them will definitely have some issues. But no need to worry ― there are solid alternatives for storing secrets securely on Kubernetes platform. One solution is to use Kamus, an open-source, git-ops solution, that created by Soluto, for managing secrets on Kubernetes. Kamus can encrypt a secret so it can be decrypted only by your app on runtime - and not by anyone else. The first part of this session will cover the challenges faced when using Kubernetes secrets (from a usability and security point of view). The second part will discuss some of the existing solutions (Sealed Secrets, Helm Secrets and others), their pros, and cons, and then feature Kamus: how it works, what problems it solves, how it differs from other solutions, and what threats it can help mitigate (and what threats it can’t). The talk will cover all that is required to know so you can run Kamus on your own cluster and use it for secret management. Join me for this session to learn how you can build a Kubernetes cluster than can keep a secret ― for real. Speakers Omer Levi Hevroni   Kubernetes Secrets     Bad, because manifest files hold the user/password, and are encoded in Base64         Could be uploaded to git = super bad https://kubernetes.io/docs/concepts/configuration/secret/ https://docs.travis-ci.com/user/encryption-keys/   Kamus threat model on Github: https://kamus.soluto.io/docs/threatmodeling/threats_controls/ https://medium.com/@BoweiHan/an-introduction-to-serverless-and-faas-functions-as-a-service-fb5cec0417b2     “FaaS is a relatively new concept that was first made available in 2014 by hook.io and is now implemented in services such as AWS Lambda, Google Cloud Functions, IBM OpenWhisk and Microsoft Azure Functions.” Best practices: https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/ https://github.com/owasp-cloud-security/owasp-cloud-security https://www.omerlh.info/2019/01/19/threat-modeling-as-code/ https://telaviv.appsecglobal.org/   https://github.com/Soluto/kamus   https://kamus.soluto.io   Infosec Campout = www.infoseccampout.com

In episode 24 of The Secure Developer, Guy is joined by Omer Levi Hevroni, DevSecOps Engineer at Soluto, to discuss application security, OWASP, security ‘mavens,' and more. The post Ep. #24, Application Security with Omer Levi Hevroni appeared first on Heavybit.

In this episode we speak with Ishay Green, a serial entrepreneur and investor after 2 exits (and 2 secondary exits - don’t worry he explains what that means). Ishay seems to have figured out the formula for making money, or as he calls it “he sees the machine”. We talk about what he looks for when considering investing in a startup. What differs between startups that have figured out the money machine and those that haven’t. And what this all has to do with “the Uber napkin”. We asked Ishay how come he sold companies with a clear potential to make him a billionaire. He answered that the amount of money that you need is equal to the force you want to apply on the world. He feels he has enough money to retire so he can afford to focus on creating the impact he wants on the world. We talk about the role of the CEO in a startup - Ishay believes the CEO is the king of the company with almost limitless powers. He shared that in retrospect, he feels that had he been the CEO in companies he’s sold, he could have led them further than the point he was able to without the powers of the CEO. Ishay believes that the chances of creating a billion dollar startup nowadays are against entrepreneurs. He explains why and what it has to do with the “frequency graph”. Hint: you’d need to create a new heroin in a world where heroin already exists. We talk about the scary brainwashing process we’re all exposed to as a society. Through online platforms, a few large companies are basically controlling our brains and decision making processes. Ishay backs this up with data from an academic research that has yet to be published but proves this isn’t fiction. It’s real and none of us are above it. Checkout the full interview and enjoy your listen

Eido Minkovski is a strategic and media consultant to some of the biggest high tech companies in Israel, including: Soluto, AOL, MyHeritage, Outbrain and more. "PR is not physics, it's simple: connecting people, thinking about ideas for stories and working hard. That's all." Coming from the background of night clubs and than IDF's spokesperson- he realized that connecting people is his biggest skill and decided to devote himself to the profession. He was than the spokes person for Haifa's municipality, until one day during a meeting the municipality had with an high tech company, the CEO was so impressed that he convinced Eido to leave the municipality and come and work with him. Since than, Eido built his own company and he's on his way to the top. "I want to be the biggest firm in Israel" In our conversation we talk about the relevance of PR in the world of new media, failure and the feeling of being an extrovert and needing to stay behind the scene, behind his clients.

Saul Klein is Founding Partner at LocalGlobe, Former General Partner at Index Ventures, Co-Founder and CEO of Seedcamp, Kano and Lovefilm International. Saul Klein joined Index Ventures in 2007 and was a Partner until May 2015. Saul has invested in early-stage internet companies including AlertMe, Chartbeat, GlassesDirect, Soluto, MyHeritage, andSongkic. A serial entrepreneur with two decades of experience building and exiting companies in both the US, Israel and Europe, Saul has a passion for working with seed and early stage businesses. Most recently he co-founded Kano and Seedcamp, as well as co-founder and original CEO of Lovefilm International (acquired by Amazon). Saul is also a Founding Partner of The Accelerator Group (TAG), which he started with Robin Klein in 1999 as a vehicle for investing in early-stage internet services, e-commerce and digital media businesses. The TAG portfolio includes bit.ly, Erply,Lovefilm, MOO, Songkick, Spot Runner,Tweetdeck,and Twitterverse. He was part of the original executive team at Skype (acquired by eBay). He has also been a board member of Codecademy and Mind Candy for years. Saul believes tech is still only just starting to make a dent on the economy and society and that it has the potential to create hundreds of thousands of jobs. He has a Master of Arts degree from Magdalene College, Cambridge. His talk at London Business School is part of the 2015-2016 Tell Series talks and it was recorded on 3 February 2016 at London Business School. Learn more about entrepreneurial opportunities at the School: http://bit.ly/LBS-entrepreneur Learn more about Tell Series: http://tellseries.com/ Learn more about DIIE: http://www.london.edu/diie

Martin Mignot is an early stage investor at Index Ventures where he specialises in SaaS, marketplaces and mobile. He is actively looking after Index's investments in Algolia, Blablacar, Capitaine Train, Deliveroo, Drivy, Rad, Swiftkey and TheFamily. He worked on 50+ transactions to date, including Assistly, Auxmoney, BaseCRM, Cloud.com, Codecademy, DimDim, Factual, Farfetch, Flipboard, Funding Circle, Gluster, HouseTrip, Just-Eat, Lookout, Nastygal, Notonthehighstreet, Onefinestay, PeoplePerHour, TrustPilot, Soluto and SoundCloud.  Prior to joining Index, Martin was in the TMT team at UBS Investment Bank and co-founded the beauty subscription business Boudoir Prive (acquired by Joliebox/Birchbox) and a student web radio service (www.rsp.fm).   A special thank you to Mattermark for providing all the data displayed in today's show and you can find out more about Mattermark here!    Click To Play   In Today's Episode You Will Learn: 1.) Where did it all start for Martin? What is the Martin Mignot story? 2.) How does Martin view venture as a career vs coming into it later on? Why does Martin think venture is now a viable career from the offset? 3.) Does Martin agree with Sheryl Sandberg’s statement, it doesn’t matter where you sit, as long as you have a seat on the rocketship? How important is valuation for Martin when making the decision? 4.) How Martin goes about sourcing the latest and greatest startups from the European ecosystem? 5.) How does Martin evaluate founders and consider their ability to execute on their plan, prior to making the investment? 6.) Talking of difficulty for startups attaining funding, what are your thoughts on VC founder alignment? You have said to focus before on the business and not the team, unless exceptional cases prevail, this is very strange for me to hear. Why is it you have adopted this stance and why do you feel it is best? Items Mentioned In Today's Episode: Martin's Fave Book: I Have America Surrounded by Tim Leary Martin's Fave Blog or Newsletter: Ben Evans Newsletter   As always you can follow The Twenty Minute VC, Harry and Martin on Twitter here! If you would like to see a more colourful side to Harry with many a mojito session, you can follow him on Instagram here!

- Soluto.com conoce el estado de tu PC desde cualquier lugar

Ugens episode omhandler en start op manager som vil analysere hvilke programmer der starter og hvilke der kan undlades for at få din maskine til at starte hurtigere. Programmerne kan enten forsinkes eller stoppes fra at starte helt. Dette program giver også en fin oversigt og sammenligning mellem din maskines originale boot/start tid og den […]

Ведущие программы Игорь и Михаил проводят собственное расследование в отношении некоторых сетевых сервисов, говорят о чудесах и обсуждают полезные сетевые находки. В программе: — Следите за Чемпионатом Мира по футболу 2010 вместе со спец. проектом Twitter’а. — Экономим на квартплате с помощью установки водных счетчиков. — Kayak Explorer поможет найти места, куда можно улететь за имеющуюся сумму денег. — Soluto — помощь в настройке автозагрузки вашего компьютера. — ВИДЕО: быть вегетарианцем только по будням. — Советы Google Россия по составлению правильного резюме. — Документальные фильмы от BBC для свободного просмотра. — Отличная подборка бесплатного софта для MacOS X на все случаи жизни. Твиттеры ведущих: Игорь @patefon, Михаил @naservere