יום ראשון, 16 בספטמבר 2018

350 Bumpers 51 for kids

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

יום שבת, 1 בספטמבר 2018

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)
      • חינם
      • תנאי שימוש מוגדרים
    • ברגע שהוגדרו התנאים, כולם חייבים לעמוד בהם - ראינו מקרים שזה לא קורה.
  • נניח שאני היום מפתח בחברה קטנה, שעדיין לא הגיעה לשלב שמצדיק השקעה במוצר כמו של WhiteSource - מה כן כדאי לי כבר לעשות?
    • אם אני כותב קוד ומשתמש בקוד פתוח (שכנראה טוב ממה שאני כותב בעצמי, ולו מכיוון שעבר הרבה יותר ידיים ועיניים) - חשוב לעקוב אחרי מה שאני משתמש בו, אילו ספריות באות יחד עם הספרייה הספציפית, מה הן התלויות, וכו’.
      • יש כלים חינמיים (דוגמא - NPM) שמאפשרים לייצר עץ-תלויות (Dependencies Tree) כולל רישיונות. זה אמנם לא מחקר מעמיק, אבל עדיין מאפשר את ההבנה הראשונית, ולפעמים (כמו עם NPM) כולל גם חשיפות (vulnerabilities) ידועות.
  • חזרה ל-WhiteSource
    • החברה מונה כ - 100 עובדים
    • הוקמה וגדלה בישראל, כיום ~70% בישראל ויש עוד סניפים, בעיקר במזרח ארה”ב - בוסטון וניו-יורק - אבל גם בחוף המערבי, באנגליה ועוד.
    • הפיתוח נעשה ברובו בישראל (כיום משרדים במגדלי בסר בגבול רמת-גן / בני ברק, מעבר קרוב למגדל השחר בתל אביב / גבעתיים).
    • האתגרים רק הולכים וגדלים.
    • החברה היום אחרי סבב השקעות שני (גיוס אחרון לפני כשנה)
      • 10~ מיליון דולר, 80% מקרן השקעות, 20% ממיקרוסופט
    • יש הרבה שיתופי פעולה עם מיקרוסופט, שמשקיעה הרבה בשנים האחרונות בקוד פתוח (ורכשה את GitHub)
    • הרבה חלקים מהמוצר הם קוד פתוח בפני עצמם.
  • עוד דבר לפני סיום - כיום ~7% מהספריות בעולם מוגדרות כרגישות (vulnerable)
    • כשמסתכלים רק על ה-100 המובילות, זה כבר עולה ל ~32%.
    • זה לא בהכרח מצביע על ספריות יותר פגיעות, אלא (גם) על זה שמחפשים בהן יותר.
    • צריך להיזהר :-)
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

יום ראשון, 26 באוגוסט 2018

348 ZipRecruiter with Yaniv Shalev

פרק 348 מארחים את יניב שליו ונדבר על חברת ZipRecruiter בה יניב עובד

  • 1:06 יניב מציג את עצמו
  • 2:18 יניב מספר על ZipRecruiter
  • 4:08 מדברים על פתיחת הסניף של ZipRecruiter בישראל
  • 5:40 רן שואל על סוג הדאטה, ואיך ZipRecruiter עושים התאמות אינטיליגנטיות, יניב מספר על פיתוח המודלים שלהם וטיוב המידע
  • 8:25 אורי מדבר על סיגנלים בשלבי הראיונות עבודה ומדגיש שאת הסיגנל החיובי מקבלים בשלב מאוד מאוחר, יניב מספר איך זה משפיע על המודל שלהם ושהם מתרכזים כרגע בהתאמה הראשונית
  • 12:15 רן שואל האם זה מוצר שניתן להשתמש בו כרגע בישראל, יניב מסביר שמבחינה עסקית הם מתרכזים כרגע באמריקה הצפונית
  • 12:38 אורי שואל האם ZipRecruiter מתבססים על מידע טקסטואלי בלבד או שיש עוד מקורות מידע, יניב עונה ומסביר איך הם מתמודדים עם ל cold start, בעיה מוכרת ב AI
  • 14:45 יניב מספר על תרבות הפיתוח ושיטת ניהול הפרויקטים היחודית ב ZipRecruiter
  • 17:42 יניב מספר על מערכת A\B Test פנימית שהם בנו
  • 20:22 דוגמא לאיך ZipRecruiter מכניסים שירותים חדשים בצורה אינקרמנטלית
  • 22:44 מדברים על ההשפעה של שיטת ניהול הפרוייקטים על המבנה הניהולי של ZipRecruiter
  • 25:12 רן שואל האם הגישה עובדת גם בצוותי תשתיות
  • 28:30 איך מעבירים ארגון לעבוד עם כלים חדשים וסביבה סקיילבילית
  • 32:25 היה חשש ב ZipRecruiter שבגלל שהצוותים אוטונומים, במעבר יווצרו פערי מידע בין הצוותים והתוצאה הסופית תהיה פחות טובה מהמצב הקיים
  • 34:00 יניב מספר על הגישה בה נקטו להפרדת האפליקציה מהתשתית עליה היא רצה
  • 37:00 רן שואל האם הצוותים ביצעו את המעבר בעצמם
  • 38:35 מדברים על מבנה הצוותים ב ZipRecruiter והיתרונות בצוותים בין יבשתיים

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

יום חמישי, 23 באוגוסט 2018

347 Bumpers 50

רן, אלון, ודותן בפרק מספר 50 (!) של באמפרס.

רגע לפני - כנס רברסים 2018 מתקרב: 8-9 באוקטובר, אוניברסיטת תל אביב. האג’נדה כבר ידועה. בואו.

  • פרויקט של המאזין דב אמיר - Awesome Design Patterns. מימוש של Design Patterns בשפות שונות ועוד כל מיני מסביב, כבר עם מעל 7600 כוכבים ב GitHub.
  • השפה Fo - כמו Go רק עם עוד כמה פיצ’רים פונקציונליים כמו Generics - מבני נתונים ופונקציות גנריים. ולא - זו לא פארודיה, זה ניסוי שאפילו נראה די עובד.
  • ג’ון רסיג (John Resig) - היוצר של jQuery (עכשיו ב Khan Academy) תומך ב-GraphQL (כמחליף של REST) ועתיד לפרסם ספר בנושא, שהפרקים הראשונים ממנו כבר זמינים. אפשר לקרוא גם בבלוג שלו.
  • תמיכה ב-SQS ב AWS Lmdba - עד עכשיו הייתה תמיכה באיוונטים מהמון מקורות, עכשיו גם SQS. אחד משדרי הפודקאסט (“א”) כבר משתמש ב-Production - עובד, אבל עדיין אין תמיכה ב- FIFO (פיצ’ר חדש יחסית).
    •  אם זה חשוב לכם אז אפשר לנסות את Kinesis, אם כי זה לא בדיוק אותו הדבר.
  • שמעתם על DevOps? או על הקונספט של Cloud Native? תהיתם מה ההבדל? הנה מצגת שמציגה את ההבדל (לדעת כותב המצגת)
    • בגדול DevOps עוסק ב- CALMS בעוד Cloud Native מתרכז סביב תת-קבוצה של זה - Automation-Lean-Measurements (מאפשר ל- DevOps). 
  • החדשות המרעישות של השבוע - פייתון! גוידו ואן-רוסום (Guido van Rossum), מייסד השפה, הודיע שהוא מפסיק (אייטם אחד פחות לפרק 1 באפריל הבא). 
    • I'll still be here, but I'm trying to let you all figure something out for yourselves. I'm tired, and need a very long break.
    • אובדן אמון? מאבקי ירושה? משחקי הכס? שובו של פייתון 2? יהיה מעניין - פייתון 3 כיום בפריסה, פייתון 2 עם EOL ב-2019.
  • פרויקט Chromeless - להריץ Headless Chrome על AWS Lambda. אפשר להפעיל מכל מקום בלי להתעסק עם כלום - יש דמו (על Netlify).
  • פונקציית Sort שעובדת רק כשתמסתכלים עליה. זה עדיין לא החלק של הבדיחות - השתמשו כאן בספרייה מאוד נחמדה שנקראת Tracking.js, שמאפשרת המון דברים שקשורים לזיהוי תמונות ועוד.
  • פוסט מעניין שמרכז את 11 ספריות ה-JavaScript שאתם צריכים להכיר ב-2018 -  שווה לעבור.
  • דוח מצב - קצת סדר ב-React Native. בעיקר ענייני ביצועים (Performance). כל העניין מרגיש קצת תקוע, אולי מעט לחץ.
  • שפת תכנות בשם Crystal - ביצועים מאוד גבוהים, תחביר כיפי, שווה לנסות (הנה מישהו שמסביר למה זו השפה הבאה שלו). שווה לשים לב ל -Command Line Apps, מרגיש כמו שילוב בין Go לבין Ruby, הבנצ’מרקים נראים מאוד מעניינים.
  • יצא Node.js v10.5.0 -  תמיכה ב-Multi-threading. עדיין ניסיוני (--experimental-worker flag)
  • סלאק היה למטה לכמה שעות טובות, ללא Post-Mortem עדיין (לא מתאים לכזה סדר גודל). משהו כמו 3-4 שעות, כולל כמה הודעות שווא על חזל”ש עד שחזר באמת. אנשים ניסו להיזכר איך לכתוב מייל.
  • רוצים להיזכר במבני נתונים? סוג של קורס 101 ב  Data Structure Zoo - זמני חיפוש, מיון וכל מה שרציתם לדעת ו(נגיד ש)שכחתם.
  • פרויקט MicroPython - מצלמה עם בקר וכל מיני התקנים שמחוברים אליו. אפשר להריץ כל פעם פקודה ולראות מה קורה. מוזמנים לשחק - משעשע ומלמד.
  • קצת שינויים ב VS Code - יש תמיכה ב - Grid layout. אפשר לפצל את המסך בכמה אופנים.
    • וגם gitlens - מאפשר לראות בכל שורה הרבה פרטים על ההערות, מי ולמה - מומלץ בחום.
  • פריצה ל - eslint, פרויקט שמורץ ע”י הרבה ספריות. 

  • תוסף חדש ל-GraphQL, עבור VSCode, של Prisma.io
    • קבוצה שנקראה בעבר GraphCool - עשו שינוי כיוון לכלים למפתחים תחת GraphQL.
  • פרויקט GraphQL stack - מאפשר לבחון את כל הרבדים של המשמעות של “לאמץ GraphQL”, לתכנן מראש ולהבין את האפשרויות.
  • לועדה (TC39) שמתכננת את עתיד של Javascript נוספה הצעה לשיפור בשם Slice notion - בדומה לפייתון ול-Go. כולל נקודת התחלה, גודל הקפיצה ועוד. 
    • אפשר לעקוב אחרי תהליך האישור, ואם וכאשר - להשתמש ב-Reference ולהתחיל לשחק עם זה (אין קומפיילר שצריך לשנות).
    • אם יאושר, סביר שמתישהו יופיע גם ב-TypeScript.
  • תיאור של מעבר מ-Node.js ל-Go, בהתייחסות ל-GraphQL
    • אמ;לק - 
      • מצאו את עצמם עם קוד שאינו Type-safe, לא מצאו את הידיים ואת הרגליים.
      • ברגע שעברו, ראו שיפור משמעותי בביצועים וצריכת זכרון (x8)
    • באופן כללי - יש קושי בספריות של Go ל-GraphQL
  • אחד הכלים היצירתיים של הזמן האחרון - MDX: בעצם JSX עם Markdown
    • כעקרון Markdown כבר תומך ב-HTML, אבל אף אחד לא חיבר את זה קודם.
    • ההבדל מ-React Markdown - אפשר להשתמש ברכיבים שלך מתוך הקוד (בתיעוד למשל)
    • בין הכותבים יש שני נציגים מ-ZEIT - נראה כמו צוות מאוד מרשים של מפתחים, ומוצר מאוד מעניין.
  • בהמשך ל- React 16.4 - יש כאן פוסט על פרופיילר (Unstable עדיין) נסתר יחסית.
    • בשורה התחתונה - זה כנראה מיועד עבור React א-סינכרוני. כרגע לא דחוף, אבל שווה לדעת שזה קיים.
  • טרנד  חדש - React Headless Components (בונים חלק של React ועוצרים ב-UI).
    • דוגמא לספרייה של Paypal בשם DownShift.
    • מאפשר גמישות שימוש ברכיבים השונים בפונקציה בהתאם לצורך בפועל.
    • שווה לשים לב האם תוספת הסיבוכיות בפיתוח שווה את זה (על פני ליצור פשוט שני מצבים).
  • ספרייה חדשה בשם Requests-html של Kenneth Reitz - המשך ל-Requests (גם שלו).
    • אם השתמשתם קודם ב-BeautifulSoup - כנראה שגם הוא, אבל שווה לעקוב.
  • אייטם יותר מרעיש - פייסבוק הכריזו על עוד פרויקט שהם פותחים כקוד פתוח - XAR
    • המטרה היא ליצור יחידות הרצאה עצמאיות (self-contained exes)
    • מהיר יותר מ-PEX, ואפילו מ-Shiv (של לינקדאין).
    • שטח הבעיה - למשל אם רוצים לפרוס ללא שימוש ב-Docker (לדוגמא - במקרה ויש בעיה עם גודל של Image שלא לצורך).
  • פרויקט 1-liners - מעבר ליכולת לעשות משהו מגניב בשורה אחת, זה גורם לחשוב. מפורק יפה (כולל קוד בצורה נוחה), שימושי לכל מי שמתעניין בתכנות פונקציונאלי (functional programming).
  • תחת פרויקט Compositor יש כמה תתי-פרויקטים, ואחד מהם הוא kit - כלי שמאפשר ליצור ויזואליזציה של React (ולהציג את מה שבנית) - 
    • אם נכנסים לעומק, רואים שמאחורי זה יש כלי בשם styleguidist - כמו Storybook, מוכוון UI.
    • בשני המקרים רוצים לתאר מעיין ספרייה סטנדרטית (“רשמית”) של רכיבי ה-UI, על פניו Storybook מוכוון מפתחים ו-styleguidist מוכוון אנשי Product ומעצבים.
  • ספרייה חדשה בשם React native reanimated - יש כבר כמה כאלה, זו יותר אמביציוזית, ללא תחרות מבחינת ביצועים. מבחינת API די דומה לקיים.
    • מסוג הדברים שנוטים לעבוד טוב ב-iOS ופחות באנדרואיד, שווה לשים לב.
  • וידאו - בניית Containers from scratch. שיחה חיה, ובנייה תוך כדי.
  • חזרה לבייסיק - בסיס הפילוסופיה של Unix. שווה ומאפשר הבנה יותר עמוקה של מה שנבנה על זה.
  • אתר שנקרא [docopt] - חיבור בין מסכי העזרה ל-CLI. שנוי במחלוקת אבל מאוד אפקטיבי.
  • פרויקט בית חכם - home-assistant.io. הכל על בסיס קוד פתוח. בישראל אין (זמין) את כל מה שיש בארה”ב, ועדיין הפעם זה נראה כמו ניסיון טוב - כתוב בפייתון, יש אפליציית מובייל, שווה לנסות אם יש לכם את הזמן.  יש מצב שיהפוך למסחרי באיזשהו שלב.
  • בלומברג (פיננסים, מדיה, תוכנה, הכל) פותחים בחינם את קורסי ההכשרה שלהם ל-Machine Learning. המון חומר, נראה מדהים.
  • פרויקט GitHub בשם machine-learning-template - מגיע מתוך ספר (מומלץ) בשם Hands-On Machine Learning with Scikit-Learn and TensorFlow. מאוד פרגמטי, לא רק תיאוריה ומתימטיקה.

בדיחות למתכנתים - 
  • בלוג נחמד בשם AIweirdness.com של Janelle Shane - אלגוריתמים של AI ושל Machine Learning טועים בצורה מצחיקה (“ממה מורכב הפוני? - 90% מתכת”, וכאלה). או נכשלים בכוונה במבחן טיורינג, תלוי איך מסתכלים על זה.
  • בלוג - The Saddest Moment, על סבילות לנפילות (fault tolerance) של אלגוריתמים מבוזרים. כתוב באופן הומוריסטי ומתאר דוגמאות נאיביות שלא מחזיקות במבחן המציאות.
  • ועוד שטויות של AI - תמונה של שני אנשים עם חליפות סקי על רקע עצים. מה יכול להשתבש? יצא מאוד יפה. יש עוד כאלה בבלוג שמוזכר באייטם הקודם.

וגם לסיום - כנס רברסים 2018 מתקרב: 8-9 באוקטובר, אוניברסיטת תל אביב. האג’נדה כבר ידועה. בואו.

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