350 Bumpers 51 for kids

באמפרס מספר 51 עם רן אלון ודותן, הפעם הפרק מוקדש לילדים

• סטארטאפ ישראלי המלמד ילדים לתכנת Code Monkey
• סט מחברות Jupyter כדרך לימוד אינטארקטיבית עבור ילדים בגיל מבוגר יותר 12+
• אפל העשירו את swift playground ניתן להוריד אפליקציה ולכתוב קוד עבור מספר אמצעי חומרה
• מנוע משחק רטרו בשם pico8 המאפשר לעצב ולבנות משחקים, והגרסא החינמית https://tic.computer/ 
• דותן מציג מספר פרוייקטים הקשורים לסאונד:
• מקלדת שליטה לחיבור בין סאונד ומחשב, ניתן לחבר לתוכנת סאונד ולייצר חוויות
• בניית קונטרולר סאונד עם Raspberry PI
• בניית מידי קונטרולר עם מדפסת תלת מימד
• דיבור לטקסט עם nodeJS בשם Sonus
• פרוייקט בשם toneJS מעין סינטיסייזר ב JavaScript
• פרוייקט בשם sonic-pi המאפשר להפוך Raspberry PI  לתחנת ייצור מוסיקה
• ערכה לבניית מעגלים חשמליים מורכבת בקלות כמו לגו לגילאים צעירים
• קיט בניית רובוט עם Arduino לאחר הבנייה ניתן לתכנת את הרובוט לכל מיני משימות
• אלון מציג מספר משחקי אייפד המלמדים ילדים לתכנת
• משחק קל בשם Robotizen משחק מסוג הזז את הצב לגילאי 4-5
• משחק הזז את הצב יותר מתקדם בשם Move The Turtle לגילאי 8+
• משחק למתכנתים בשם Cargo-Bot 
• משחק מחשב בו המטרה להזיז דמות ממקום למקום ע״י הזזת בלוקים או ע״י Java Script
• בכנס רברסים הקרוב תהיה הרצאה של אורי נתיב יחד עם הבת שלו בה הם יציגו פרוייקטים שהם עשו יחד בעזרת Arduino

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

349 WhiteSource

פודקאסט מספר 349 - אורי ורן מארחים בשלהי החופש הגדול את אסף סביץ’ לשיחה על WhiteSource וניהול השימוש בקוד פתוח.

• רגע לפני - כנס רברסים 2018 מעבר לפינה (בימי עבודה בארץ זה קרוב לחד-ספרתי) -  8-9 באוקטובר, אוניברסיטת תל אביב. בואו.
• אסף - בן 28, עובד ב WhiteSource כשנתיים וחצי (לפני כן שני סטארטאפים, אלביט).
• ב - WhiteSource מתעסקים בכמה תחומים -
• ראשית - One Stop Shop לעינייני קוד פתוח (Open Source) - על מנת לפשט עבור הלקוחות את השימוש בקוד פתוח.
• 70-80% מהקוד שחברות מוציאות היום מבוסס על קוד פתוח, וכל תהליכי הבדיקות והאוטומציה מתבצעים על ה 20-30% הנותרים. זה עלול להיות בעייתי.
• רן - המודלים המוכרים הם לדוגמא של RedHat, שמספקים שירותי תמיכה וערך מוסף לבסיס הקוד הפתוח (מודולים נוספים למשל); לרוב מדובר במוצר אחד ספציפי (או כמה), עבור ארגונים מאוד גדולים.
• ב WhiteSource אולי לא יפתרו באגים ספציפיים בקוד הפתוח, אבל כן יכולים להתריע על סיכונים, על אי-הלימה עם מדיניות החברה, להנגיש מידע רלוונטי על הסכמי השימוש וגם על באגים ידועים בקוד הרלוונטי. 
• הקהילה משתפת המון מידע מהמון מקורות, ויש צורך לעשות סדר ולהתאים את מה שרלוונטי - לאפשר מיקוד ביתרונות השימוש בקוד פתוח, ולהתעסק פחות בחסרונות.
• זו יכולה להיות התרעה על פרצות אבטחה ידועות, אבל לפעמים גם פשוט לדעת שיצאה גרסה חדשה שיכולה להיות רלוונטית זה לא משהו שפשוט לשים לב אליו לב עבור הרבה מוצרים.

• מאיפה הכל התחיל? 
• שלושת היזמים של החברה התחילו בחברה שנקראת Eurekify (שנרכשה ע”י CA), וכחלק מתהליכי הרכישה ובדיקת הנאותות (Due Diligence) היו צריכים להסביר מאיפה הגיע כל דבר, כולל הקוד הפתוח. 
• הם גילו שזה לא כל כך פשוט, ושאין פתרון קיים מספיק טוב (Black Duck הייתה קיימת, לא הרבה מעבר), והחליטו לפתוח חברה שתיתן מענה. שנה לאחר מכן הוקמה WhiteSource.
• החברה גדלה, אסף הגיע לפני שנתיים כעובד ה -13, היום סדר גודל של כ-100 עובדים.
• מתחרים - השימוש בקוד פתוח הולך וצובר תאוצה, עם בערך 7 חברות עיקריות בשוק - WhiteSource ו - Black Duck מובילות.
• רן - כשהחברה קטנה, לא מאוד מסובך (יחסית) להבין באילו ספריות קוד פתוח נעשה שימוש. העניין מסתבך כשהחברה גדלה והמעקב הופך למורכב יותר - גם חלקים שנמצאים בקוד אבל לא משתמשים בהם בפועל, וגם חלקים שלא בההכרח שייכים לקוד הראשי (אנליסטים, תמיכה וכו’). 
• החשיפה לקוד פתוח (והסיכון הנלווה אליה) הולכים וגדלים, ולרוב שמים לב לזה בכמה מקרים - הצעת רכישה, השקעה(וה - Due Diligence הנלווה אליה), או התקפה שמנצלת חולשה של אחר מרכיבי הקוד הפתוח.
• בהרבה מקרים, חבילה אחת מביאה איתה הרבה דברים “בבטן” - לדוגמא: NPM (שהזכרנו ב Bumpers האחרון), כשאפשר להתקין חבילה אחת ולקבל איתה עוד מאות חבילות נלוות.
• עוד מאות אלפי שורות קוד שהחברה לא באמת צריכה (לעיתים לא מודעת לקיומן) והגיעו “בחינם” - אבל מביאות איתן עוד “משקל” מסויים שצריך לדעת להעריך ולתכנן (ולהיערך מבחינת אבטחת מידע).
• אז איך המוצר עובד?
• ה - Use Case המרכזי הוא של כניסה בשלב ה - Build (אם כי אפשר בכל שלב): ל - WhiteSource יש עשרות Plug-Ins לכל שפה ו-Build Servers עיקריים. מוסיפים עוד שלב.
• האם ה-Build של היום עומד בהגדרת החברה? האם נוסף סיכון כלשהו? זו עוד סיבה אפשרית לנפילה (WhiteSource Fail).
• אם מצאנו נפילה ב-Build זה טוב (לא הגיע ללקוח), אבל עדיף למצוא קודם ולחסוך את העבודה שהושקעה --> כל מפתחת יכולה לסרוק ברגע שהיא הכניסה את הספריה, עוד טרם השימוש.
• יש לחברה תוסף לכרום (Chrome) שמנגיש מידע על כל ספריה באופן כללי, כבר בשלב החיפוש והסריקה.
• הבדיקה מתבצעת גם ברמת הרישיון עצמו (MIT אולי בסדר, GPL כבר עשוי להיות בעייתי להרבה לקוחות, וכו’)
• עניין מדיניות הרשיון היא לא רק ברמה החוקית - יש אספקט של חשיפה (Vulnerability), התראות על גרסאות חדשות (לדוגמא: לא חייב להכשיל את ה-Build, אבל אני כן רוצה לדעת שיש גרסא חדשה) ועוד.
• אז זה מה שהמוצר עושה - איך המוצר עובד?
• יש צוות שעוסק ב - Research, ובודק מספר מאגרים ומעדכן כל הזמן. מעבר למידע עצמו, יש גם מנגנון של מתן פתרונות אפשריים למקרה הספציפי.
• כיום בשלבי פיתוח מתקדמים של מוצר בשם Effective Usage Analysis (שם זמני) - מוצר שסורק את הקוד ברמת המפתח, ויודע להתריע במקרה שיש קשר ישר (עקבה, trace) לרגישות (Vulnerability) הספציפית. 
• יכול להיות שהקוד כולל ספרייה בעייתית, אבל בקוד עצמו אין קריאה בפועל לספרייה.
• בשפות סטטיות די מובן איך זה עובד. בשפות דינאמיות (Ruby, JavaScript, Python) זה נראה כמו אתגר יותר משמעותי.
• עבור Java כבר יש פתרון, ב - JavaScript כבר קרובים מאוד. כמות השפות הנתמכות הולכת וגדלה, וזה אכן אתגר. 
• מעבר לכך, העובדה שניתן להצביע על הקישור ישיר למקום ספציפי בקוד שעלול להיות בעייתי מאפשרת להפעיל שיקול דעת (בהינתן שיודעים איפה המקור).
• רעיון לפיצ’ר נוסף - Run-time Analysis, שבודק האם יש קריאה בפועל (בזמן ריצה). סביר שתיהיה לזה עלות (ביצועים).
• מי הם הלקוחות הטיפוסיים? 
• לרוב חברות בינוניות-גדולות (לחברות קטנות כנראה יש עדיין צרות גדולות יותר)
• חברה שיש לה הרבה מוצרים, הרבה מפתחים, הרבה פרוייקטים - והניהול הופך מאוד מורכב
• קשר מול CTO או CISO שאחראים על הטמעת המוצר, ואז הוא נגיש לכל אחד בחברה.
• האם יש יחסים כלשהם עם “יצרני” הקוד הפתוח?
• כיום פחות, אולי בעתיד.
• חשוב לשים לב שזה שקוד עולה ל-GitHub לא הופך אותו ל-Open Source - צריך שיהיה
•  זמין לכולם (Publicly available)
• חינם
• תנאי שימוש מוגדרים
• ברגע שהוגדרו התנאים, כולם חייבים לעמוד בהם - ראינו מקרים שזה לא קורה.
• אמנם נדיר שמגיעים לבית משפט על תנאי שימוש, אבל כיוון שהקהילה מאוד חזקה נוצרת אכיפה בפועל.
• דוגמא מ 2016 - Wix השתמשה בקוד פתוח של WordPress, שאמנם פתוח אבל מגדיר שגם המשתמש צריך להיות כזה. הסתיים בהתנצלות (לאחר מלחמת טוויטר קלה).
• נראה ששני הצדדים קצת אשמים, אבל בכל מקרה - נראה שעדיף לא להיכנס לכזו פינה מלכתחילה.
• עוד בנושא - מפתח-לשעבר ב-Wix שמצא את עצמו מואשם בגניבת קוד . . .
• נניח שאני היום מפתח בחברה קטנה, שעדיין לא הגיעה לשלב שמצדיק השקעה במוצר כמו של WhiteSource - מה כן כדאי לי כבר לעשות?
• אם אני כותב קוד ומשתמש בקוד פתוח (שכנראה טוב ממה שאני כותב בעצמי, ולו מכיוון שעבר הרבה יותר ידיים ועיניים) - חשוב לעקוב אחרי מה שאני משתמש בו, אילו ספריות באות יחד עם הספרייה הספציפית, מה הן התלויות, וכו’.
• יש כלים חינמיים (דוגמא - NPM) שמאפשרים לייצר עץ-תלויות (Dependencies Tree) כולל רישיונות. זה אמנם לא מחקר מעמיק, אבל עדיין מאפשר את ההבנה הראשונית, ולפעמים (כמו עם NPM) כולל גם חשיפות (vulnerabilities) ידועות.

• חזרה ל-WhiteSource
• החברה מונה כ - 100 עובדים
• הוקמה וגדלה בישראל, כיום ~70% בישראל ויש עוד סניפים, בעיקר במזרח ארה”ב - בוסטון וניו-יורק - אבל גם בחוף המערבי, באנגליה ועוד.
• הפיתוח נעשה ברובו בישראל (כיום משרדים במגדלי בסר בגבול רמת-גן / בני ברק, מעבר קרוב למגדל השחר בתל אביב / גבעתיים).
• האתגרים רק הולכים וגדלים.
• מגייסים עובדים, כמובן - הנה, כאן.
• החברה היום אחרי סבב השקעות שני (גיוס אחרון לפני כשנה)
• 10~ מיליון דולר, 80% מקרן השקעות, 20% ממיקרוסופט
• יש הרבה שיתופי פעולה עם מיקרוסופט, שמשקיעה הרבה בשנים האחרונות בקוד פתוח (ורכשה את GitHub)
• הרבה חלקים מהמוצר הם קוד פתוח בפני עצמם.
• עוד דבר לפני סיום - כיום ~7% מהספריות בעולם מוגדרות כרגישות (vulnerable)
• כשמסתכלים רק על ה-100 המובילות, זה כבר עולה ל ~32%.
• זה לא בהכרח מצביע על ספריות יותר פגיעות, אלא (גם) על זה שמחפשים בהן יותר.
• צריך להיזהר :-)

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