יום שני, 9 במאי 2016

301 Where do developers go at 40 or 50?

אנחנו בפודקאסט 301, עם אורי לביא, בפרק שנולד משאלה של עקיבא בלוך: "מה קורה לאנשים בתעשייה בגיל 40-50?"

  • 02:07 –אורי לביא, מנכ"ל חברת PicScout, מפרסם פודקאסט על היבטים ניהוליים ובכלל טיפים בניהול.
  • 05:00 – בתעשייה בעבר הייתה הסברה כי "יוצאים לפנסיה בגיל 40" – כעת שהתעשייה התבגרה מעט היא מייצרת הזדמנויות שונות לגילאים אלו (כגון: מנהל מוצר, מנהל פרויקט וכו'). בנוסף התעשייה דוחפת כל הזמן להתקדם ולכן ישנם פחות מהנדסי תוכנה בגילאים אלו.
  • 07:40 – אורי מעורב בפרויקטים למהנדסים שרוצים לחזור לתעשייה – כשפנה לחברות ההשמה הן לא ידעו להעביר אנשים רבים.
  • 08:20 – סיבה נוספת היא הגדילה שנעשה בסוף שנות ה90, תחילת ה2000 – ורק כעת הם מגיעים לגילאי ה40.
  • 10:10- נקודה נוספת, היא ניהול הקריירה של עובד מתחילתה, כשאדם מתחיל להיות מהנדס תוכנה, רוב האנשים זורמים – אין מספיק מחשבה על מה צריך להשביח בכדי להצליח בעוד 10-15 שנים. הרדיפה אחרי הקידום, אחרי התפקיד הבא פוגע בהתמקצעות – הממוצע היום הינו שנה וחצי בתפקיד.
  • 13:15- הבעיה קיימת גם בתעשיות הנדסה נוספות – אך מכיוון התוכנה הוא תחום יחסית צעיר הבעיה מורגשת יותר.
  • 15:04 – כלל ה10,000 שעות – 10 שנות נסיון – בכדי להיות מקצועי בתחום כלשהו יש צורך להשקיע לפחות 10,000 שעות (גם מחוץ לשעות העבודה). הטעות הנפוצה – צבירה של נסיון בינוני במספר תחומים. בנוסף בכדי להגדיר מקצוענים קיים מדד דרייפוס – אם נדרג כל יכולת מ1 עד 5 – יש צורך להגיע לרמה גבוהה בכמה יכולות ובנוסף להחזיק במומחיות גבוהה (5) ביכולות בודדות.
  • 19:20 – ייחוד תעשיית התוכנה – הביקוש גבוה, המשכורות גבוהות – פורסם מחקר בעבר כי בתקופת כושר ההשתכרות שוטר במשטרת ישראל מרוויח יותר מאשר מהנדס תוכנה – לכן אין להסתכל על טווח קצר וחשוב לבנות ולתכנן קריירה.
  • 26:20 – איך ניתן לנהל קריירה נכון? – ראשית, באקדמיה יש צורך בשינוי התכנית בכדי שתתאים יותר לתעשייה – מהו מהנדס תוכנה? איך מנהלים קריירה? – המרכז הבינתחומי הרצליה כיום יותר מחובר לתעשייה.
  • 28:07 – יש צורך ביותר חשיפה לבעיה ולהעלות מודעות שאין חובה לרוץ בין תפקיד לתפקיד.
  • 28:47 - לבסוף, יש צורך שהתעשייה תהיה מחוברת ולמוטיבציה של העובד לרצות ללמוד מחדש למרות שלפעמים ההרגשה היא של חזרה אחורה.
  • 31:05- בפרויקט של PicScout- החברה ייצרה והעבירה קורס באופן פרונטלית וגם מקוון ולאחר ההכשרה מכווינים אותם למשרות מתאימות. (לפניות jobs@picscout.com).
  • 35:12 – בחלק מהחברות קשה להתקדם קידום שהוא מקצועי נטו. כמעסיקים, חשוב לתת למהנדסי תוכנה לקדם את הטכנולוגיה.
  • 39:45- יוזמות נוספות – Outbrain פותחים Operation school (פרטים נוספים בקרוב), מועדון אפורי השיער – לאנשים שמחפשים את השלב הבא לאחר שנפלטו מהתעשיה ופורום החברות הצומחות – עקב החוסרים שקיימים מנסים למצוא מקורות לגיוס ולהכשרה.

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

יום ראשון, 8 במאי 2016

300 Carburetor 22 - InsightEdge

אנחנו בפודקאסט 300, עם נתי שלום מחברת Gigaspaces– פרק מספר 22 של קרבורטור – היום נדבר על Spark והאתגרים בשינוי המוצר המכניס העיקרי של החברה XAP  לInsightEdge

  • 2:00 - מעט על Gigaspaces – שני מוצרים עיקריים, דאטאבייס In memory מבוזר וCloudify. מוצר הדאטאבייס XAP עבר שינוי משמעותי עקב התפשטות הOpen source.
  • 6:00 – Apache Spark – פרוייקט Open source הכתוב בScala לביצוע Map-Reduce מהיר (ואף יותר), מבוסס על אבסטרקציה מרכזית של RDD’s (Resilient data store( אובייקט נתונים. נבנה בצורה אינטגרטיבית עם Hadoop (בשונה מ Storm).
  • 11:40 – המוצר של Gigaspace, שנבנה לנהל Complex data בזיכרון התומך במספר סוגי API ויכולת להריץ קוד עם ה Data. היכולות של המוצר מעניינות את משתמשי Spark. ההבדלים העיקריים היו סוג הרישיון וה API השונה.
  • 14:20 – איך מכניסים Plugin יותר מהיר מהזיכרון – שכן Spark מעבד את המידע בזיכרון – השיפור שמציעה Gigaspace היא בשינוי ה Inputs,Outputs של Spark מ HDFS למוצר של החברה. מוצרים נוספים דומים הם Tachyon ו MemSQL.
  • 20:20 – הBenchmark מראה שיפור משמעותי מול ה HDFS – היתרון המרכזי הוא בStreaming.
  • 21:50 – השינוי שנעשה בחברה - המוצר לא יוכל לכלכל את החברה לאורך זמן ולכן הוחלט על השינוי להיות Distro של Spark. לארוז את Spark עם המוצר ולהפיץ כיחידה אחת.
  • 24:40 – האם הלקוחות למוצר הם הלקוחות הקיימים או לקוחות חדשים – הEarly adopters היו הלקוחות הקיימים (כגון American airlines). פרויקט המעבר לקח כ 3 חודשים עם הצוות הקיים. כמו כן, התחרות של החברה עברה מעולם Enterprise ופרוייקטים כגון Redis לתחרות בSpark Disros. (Insightedge.io)
  • 30:37 – Economic mode – אסטרטגיית פיבוטינג לפי וורן באפט. לדוגמא סודה-סטרים – חברה נוספת שעשתה מיצוב מחדש.
  • 34:55- מודל נוספים כגון SAS (כמו שDatabricks עושים) – אך זהו שינוי ארגוני גדול יותר.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לחן על התמלול

יום חמישי, 5 במאי 2016

299 Fogcast 25 - Package managers

אנחנו בפרק 299, ה 19 למרץ 2016. בפרק זה רן וליאור מדברים על Package Managers

1:16 - תקציר הפרק על AWS Lambda, ו Serverless architecture. רן בונה Web Crawler ולבסוף החליט שלא להשתמש בשירות של Lambda. הרושם חיובי, אבל חסר למערכת בגרות בשליטה על התהליך.

4:16 - בסביבות רבות כגון  Node.js, Rails יש חשיבות עליונה ל Package Managers. ב״עולם הישן״ של C++ , לא היו Package Managers ותחזוקת גרסאות של ספריות בתוך פרוייקט הייתה מטלה כבדה ומייגעת.

5:30 - יש להבדיל בין סוגי ה Package Managers השונים. למפתח מדובר בהתקנת ספריות (למשל ב Node.js, Ruby). לעומת זאת בעולם ה Infrastructure, מדובר בהתקנת Executables על הוסט מסויים למשל apt, yam.

6:15 - הגדרה - Package Manager מאפשר משיכת חבילה, לשלוט בגרסא הנמשכת, לעדכן את הגרסא, ולטעון את כל ה Dependencies -חבילות אחרות בהן החבילה המבוקשת תלויה (התלויות שלהן). כמשתמש הציפייה היא לבקש חבילה מסויימת ושכל ההליכים הנלווים יהיו מנוהלים אוטומטית.

7:53 - נושא ניהול החבילות הדינמיות תמיד היה בעייתי. בעבר DLL Hell היה אתגר נפוץ באקוסיסטם של מערכות הפעלה Windows. הקונספט שנועד לחסוך בשטח אחסון במחשב אפשר להוריד חבילה מסויימת ולהשתמש בה במגוון תוכנות במחשב. ה״גהינום של ה DLL״ החל כאשר תוכנות שונות השתמשו בגרסאות שונות של אותה חבילה, אך החבילה הייתה מותקנת אך ורק בגרסא אחת.

9:17 - הבעיה קיימת בעוד סביבות כמו Java או לינוקס גם כיום.

10:04 - בעיית ה Versioning היא יחסית פתירה כבעיה טכנית, ובסביבות שבהן נבנה Semantic Versioning מהיסוד של הטכנולוגיה, יש סדר יחסי. דוגמאות מוצלחות הן Node.js, ROR, אבל גם טכנולוגיות אחרות מתחילות להדביק את הפער.

12:38 - ה Package Manager מאפשר שליטה במה שמשתמשים בו בפיתוח ובפרודקשן.

12:47 ה Package Managers לפי סביבות הם :
Node.js - Npm
Ruby - Gem
Python - pip
Java - Maven
          
לכל שפה או טכנולוגיה כבר יש Package manager, אפילו ישנות כמו C.

13:21 - מספרי גירסאות מנוהלים ע״י Semantic Versioning - שלוש המספרים של גרסא. המספר הראשון הוא ה Major release - משתנה בד״כ אחת לכמה שנים. המספר השני מבטא שינויים ב API ויכול להגיע גם למאות. הנקודה האחרונה מבטאת שינויים שלא אמורים להשפיע על ה API, למשל תיקוני באגים.

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

16:44 - מודל ה Semantic versioning איננו מושלם. יתכנו שינויים בתוצאות שמחזירות פונקציות מבלי לשנות את חתימתן, וכך לעקוף את מנגנון האכיפה.

17:24 - איך נמנעים מבעיית הגרסאות השונות בפרויקט אמיתי במצב בו ספריות ה Dependencies משתמשות באותה ספריה, אך בגרסאות שונות ולא תואמות? ב Java זה יכול להיות סיוט ואף ליצור בעיות רק בזמן ריצה. עם קצת מזל מוצאים גרסא שמתאימה לכל הדרישות אך זה ידני. החלופה השניה היא שימוש ב OSGI להכלה של חבילות, אך גם זה תהליך לא נעים.

19:57 - אלטרנטיבה לפתרון היא השמה של החבילות בצורה מקבילה כך שכל חבילה מבודדת את החבילות שבה היא תלויה, זה בזבזני באחסון וזכרון, אבל לא משמעותי ביחס ליתרון. נעשה שימוש בשיטה זו ב NPM מעל Node.js.

21:36 - בעולם ה Java זה לא ממש אפשר מפני שצריכת חבילות הוא לפי שם ה Class וכך אי אפשר ליצור את הבידוד. כשכתבו את Java לא היו מודעים לקיום הבעיה, והטכנולוגיות המודרניות כבר לקחו את המכשולים הללו בחשבון.

22:42 - הבעיות הללו היו פתירות ב C++ וגם Java, אבל דורשות מעקפים ״מלוכלכים״ של עריכת הקוד בחבילות הנדרשות והקוד שאותו צורכים.

24:38 - הבעיה קיימת גם בפייתון עם Hacks כמו טעינה דינמית או שינוי Path.

26:00 - באקוסיסטם של GO, יש חידוש בתחום ה Deployment - הקומפילציה נעשית ביחד עם ״משתני הסביבה״, ויוצרת Executable בודד כך שאפשר בקלות יחסית להעלות לשרת ללא תלויות.

27:31 - קול קורא: ישנה בעיה כיום של תקשורת ״דו-כיוונית״. המשתמש בחבילה צריך לדאוג לעדכן את החבילה בעצמו, ואילו אם כותב החבילה מתקן באג קריטי, אין לו יכולת ״להודיע״ למשתמשים בחבילה שעליהם לעדכן. דמיינו את העדכונים במערכות ההפעלה - היה טוב לו הייתה יכולת זו (לדחוף תיקונים ב Push) גם בעולם החבילות וה Package Managers.

29:21 - למאזיני פודקאסטים שאוהבים מדע בדיוני - ממליצים על  Escapepod.

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

יום רביעי, 27 באפריל 2016

298 The history of visual object detection

אנחנו בפודקאסט 298, ה22 במרץ, עם אמרי קיסוס והיום נדבר על ראייה ממוחשבת וזיהוי עצמים.

  • 1:13- אמרי, מומחה בראייה ממוחשבת ובזיהוי עצמים ופנים עובד בFDNA. חברה הקיימת מעל 4 שנים ובעלת אפליקציה לזיהוי מחלות גנטיות ככלי עזר לרופא.
  • 3:40 – אילו בעיות קיימות בזיהוי אובייקטים – בעיית זיהוי פנים (Face detection) נחשב בעיה פתורה אך זיהוי למי שייכות הפנים (Face recognition) - אינה פתורה.
  • בזיהוי אובייקטים שונים מקטגוריות שונות, מייקרוסופט הוציאה מערכת לפני מספר חודשים שהיוותה שיפור משמעותי וגוגל אף שיפרה את אחוזי הזיהוי בחודשים האחרונים.
  • סוג הבעיות שמעוניינים לפתור בזיהיו עצמים בתמונות הם (קישור):
  • 7:35- סקירה היסטורית – התיעוד הראשון של זיהוי עצמים הינו ממחקר של סקינר ממלחמת העולם השנייה –לאמן יונים לזהות מטרות ועצמים ליצירת פצצות מונחות. משנות ה70 זוהי טכנולוגיה צבאית לזיהוי מטרות והטכנולוגיה "אוזרחה" בשנים האחרונות.
  • 10:42 – תחילת העיסוק באיתור פנים – המעבר למודלים מתמטיים מתקדמים ומבוססי סטטיסטיקה – המערכת הראשונה Eigenfaces) 1987)– מערכת המנסה לאתר פנים ע"י בניית צירוף של תמונות פנים קודמות.
איך נסווג פנים - אם נצליח להרכיב את התמונה ממספר פרצופי בסיס קטן - אילו פנים, אחרת הם לא פנים.
  • 13:35- הצעד הבא בזיהוי פנים (1997) – הפנים כגרף של נקודות – כמו ש"מדמיינים" זיהוי פנים. מחלקים את הפנים למאפיינים שיש לכל פרצוף וקבעו אותן כנק' חובה ואת הפרופורציות ביניהן. איתור הפנים – כמציאת התאמה בין גרפים. המודל למרות שנראה מרשים אינו עומד במציאות.
  • 16:47 – בשנת 2001 – ויולה וג'ונס – מצאו שיטה שמהווה פריצת דרך בתחום זיהוי הפנים -   השיטה מתבססת על מציאת תבנית של ניגודיות כגון הניגודיות בין העיניים לגבות ואם מספיק תבניות התאמתו כתבניות המתאימות לפנים המערכת מסווגת את התמונה כפנים. מודל יותר סטטיסטי והיוריסטי. דוגמא לטעויות באלגוריתם ניתן לראות ממצלמה של HP ב2009 שלא זיהתה פנים של אנשים כהי-עור.
  • 24:40 – ב2014 יצא מאמר Head Hunter שהראה שבפועל לא הייתה התקדמות משמעותית למרות אלגוריתמים רבים שנוצרו.
  • 25:39- Deep Learning– הקפיצה הבאה שנעשתה בתחום זיהוי הפנים. הDeep Learning  מאפשר לאמן את המערכת עם כמות הרבה יותר גדלה של תמונות מאשר אלגוריתמים קודמים. באלגוריתמים אלו, קשה יותר לרמות את המערכת – נעשה נסיון של Cornell Tech שלא הצליח לשבור את האלגוריתמים.
  • 30:45- שיוך פנים לאדם – המאמר 2014  Deep face – המאמר מוציא מאפיינים לכל אדם לפי מספר תמונות. המערכת מחשבת וקטור של הסתברויות לכל אחד מהפרטים בתמונות. השלב הראשון הוא Feature extraction ולאחר מכן משליכים את התוצאות על שאר התוצאות בTraining set.  כיום מספיק כ3-5 תמונות בכדי לזהות אדם באופן טוב.
  • 34:10- שימוש נוסף, זיהוי הבעות על ידי זיהוי נק' על הפנים.
  • 34:57 – זיהוי פנים לא באופן פרונטלי – זהו אתגר שפחות מטפלים בו ומעדיפים להתמקד בפנים "לא סטנדרטיים" כגון מייקל ג'קסון ומחלת הזיקה.

תודה רבה לחן סלומון על התקצור. הקובץ זמין כאן להורדה.

יום חמישי, 21 באפריל 2016

297 Fogcast 24 - Lambda

בפרק זה רן וליאור מדברים על AWS Lambda והנסיון של רן בכתיבת crawler מעל שרות זה.

2:10 בניית פריימוורק ל AWS Lambda עבור Yodas

3:37 המוצר AWS Lambda נוצר ע״י אמאזון עם הקונספט של ״פונקציות ולא סרברים״. אין לך סרבר משלך , המתכנת מממש פונקציה משלו ב Node.js, Python, Java או אחר. ואלו רצות על תשתיות על אמאזון מבלי דאגות של Scale.

5:00 ההבדל בין Microservice לבין AWS Lambda, אוסף של פונקציות לעומת תשתית

6:57 ההבדל המשמעותי בין Lambda לבין Heroku ו Paas אחרים הוא שב Lambda כותבים אך ורק פונקציה - היחידה האטומית היא מאוד קטנה לעומת כתיבת Service שהוא שרת שלם.

7:46 הסוד הוא ב UNIXification של התוכנה. כותבים הרבה מאוד יחידות קטנות של פונקציונליות ומחברים אותן עם כלים חזקים כמו Message queues או דאטאבייסים המייצאים Stream, והתשתית הזו מסופקת ע״י אמאזון (או ספק אחר). הכלים הללו הבשילו לרמת פרודקשן והופכים לאופציה ריאלית לפיתוח.

9:30 קונספטים של למבדה: הפונקציות הן Stateless - בין הרצה להרצה לא שומרים על קבצים, אחרי ריצה - הדיסק ״מתאדה״. כשפונקציה מתחילה לרוץ היא מתחילה ״מאפס״ - ומוזנת מ ה Event או מידע מ S3 או דאטאבייס. זה אמנם אילוץ, אך הוא דוחף לארכיטקטורה נכונה שניתן לעשות לה Scale בפשטות יחסית.

11:24 אין סרברים, לא צריך לתכנת אותם, לתחזק אותם, לנטר אותם. הכל מאחורי אבסטרקציה, ומוריד הרבה מטלות תחזוקה.

12:25 הפונקציות הן Event driven - מחכות להודעות כדי לעבוד. יכולות להיות מוזנות ע״י הזנה לחלק אחר מהאקוסיסטם של אמאזון - S3, SQS, Kinesis, Dynamo DB. לדוגמא, אפשר לכתוב פונקציית Lambda, שבכל הזנה של קובץ תמונה ל S3, מייצרת עבורו גם Thumbnail (תמונה מוקטנת). הפונקציה תופעל לאחר שהוספת הקובץ ל S3, תבצע  ״Trigger״ באופן אוטומטי של ה״Event״.

13:45 שימוש ב Api Gateway של אמאזון כדי לחבר גם פעולות שמקורן בווב. זו אבולוציה של ה Lambda שהחל כיכולת ״פנימית״ בלבד לארכיטקטורה ואח״כ התווספה היכולת לקבל איוונטים מבחוץ ולהחזיר תשובות.

15:10 הקונספט של ״Infinite Scalability, Zero maintenance״ - כמובן בגבול הסביר.

15:41 גוגל הכריזו על Google cloud functions - אלטרנטיבה ל Lambda שנמצאת באלפא וכרגע תומכת רק ב Node.js.

16:10 שירות בשם iron.io שגם מציע אלטרנטיבה דומה.

16:55  סכנת ה Lock-in לספק השירות הספציפי - למשל ב AWS, התשתית תהיה תלויה בשירותים המשלימים של אמאזון ונוצרת סכנה של  ״Vendor Lock in״. הקוד עצמו (הלוגיקה) גנרי ולא תלוי תשתית, אך התלות ב״דבק״ - השירותים שמשנעים את המידע, מאוד תלוי ספק.

18:40 דוגמא איך הבדלי סמנטיקה בין ה Message Queues יכולה להשפיע על המימוש וליצור Lock-in, אפילו למוצר מסויים בתוך אותו השירות (כמו SQS לעומת Kinesis ששניהם שירותי תורים של AWS).

20:45 זה לא לחלוטין ניתן להעברה. יש Vendor Lock in גבוהה יותר מאשר כתיבת שרת ״old fashioned״, של node+ express, אבל זה צפוי להשתפר.

21:52 בטווך הארוך הרעיון הוא לבנות תשתית פונקציונלית בסיסית, והציפייה היא שהשירותים יישרו קו ויתמכו בפורמטים דומים.

23:00 טוב שיש תחרות מגוגל - כי יש בעיות רבות ואמאזון צריכים תחרות

23:30 מימוש: אפשר לכתוב Node.js, Python, Java או לכתוב Shim שיאפשר לכתוב בשפה אחרת - למשל Go, ע״י הרצתו כ Process עם Input - output. פריימוורק שמאפשר את זה מבלי לכתוב את ה Shim בעצמך הוא Apex.

24:57 התהליך של העלאת הפונקציות וניהולן די מתיש מול הממשק של AWS, ובגלל שצריך גם ניהול קוד. Apex נותן פתרון טוב ל Version control, Deployment, Rollback ותמיכה ב Go בנוסף לשפות שמוצעות ע״י Lambda.

27:00 בנוסף Apex נותן יכולות טובות לחיבור הפונקציות ל Events וניטור של התהליך. הניהול הזה הוא חלק נכבד מתהליך הפיתוח ב Lambda.

28:03 ב Apex החליטו לעבוד עם Terraform, כלי לניהול ה Infrastructure בענן. הכלי יכול לשמש למגוון של use cases להגדרת התשתיות בקוד (עם Version control). ב Apex השימוש ב Terraform הוא די הכרחי. ייתכן כי Apex יתרחב בעתיד מעבר לתשתיות של AWS בלבד.

31:31 נקודת התורפה בקונספט - האם באמת נחסך הצורך בלימוד כלים לניהול ה Infrastructure? אכן הניהול הוא נקודת חיכוך משמעותית ב Flow של Lambda.

32:43 זה יהיה הרבה יותר נחמד אם זה פשוט יעבוד. זה לא בשמיים לחבר פונקציה לתור והאבסטרקציה תגיע בקרוב. AWS LAmbda עוד צעיר ונמצא בגרסא 0.7

33:57 פריימוורק נוסף Serverless גם מנסה להתחרות בספייס הזה - להריץ Lambda על עננים שונים (כרגע רק באמאזון). Apex יחסית פשוט יותר, אבל שניהם בכיוון הנכון. חיוני להשתמש באחד מהם כדי לעבוד עם  Lambda.

35:09 ניהול התשתיות הוא נקודת חיכוך שקיימת גם ככה בניהול שרתים ״Old school״. עדיף לעשות את זה נכון עם ניהול הרשאות

36:05 ה Tool fatigue מהאקוסיסטם של Javascript מגיע גם ל Devops, ולימוד של כלי חדש (כמו Lambda) מכריח ללמוד כלים נלווים נוספים.

38:28 יש מגוון Use cases. למשל Api Gateway + Lambda. שירות Cronjob (למשל שליחה ל Slack פעם ביום בשעה 10). דוגמא נוספת ל Slack היא שליחת הודעות בתגובה ל Events בתשתית (העלאת שרת, הורדת שרת). העלויות זניחות למקרה שבו ה Workload נמוך - זה עדיף מהחזקת שרת לצורך המשימה.

40:44 שימוש ב Analytics. חברת Segment.com פרסמה תיאור מעניין של Data pipeline בעזרת Lambda. זה יכול לשמש גם לניתוח מסוג Crawling. העלויות לעיבוד בקנה מידה גדול משמעותיות, וזה יכול להוות פקטור בבחירת הטכנולוגיה.

43:21 מימוש Data pipeline באמצעות Lambda Architechture, המימוש של AWS Lambda דומה בקונספט ל Use case של Data processing - פונקציות קטנות שהן Stateless שעושות את עבודתן ומעבירות הלאה. לא להתבלבל בין שניהם.

44:55 מימוש של רן ל Crawler הוא ניסוי. כרגע נראה שזה לא משתלם מבחינת זמן, אבל רק בעתיד נדע.

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

48:10 ב Bringg מגייסים מתכנתי iOS.

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

יום שני, 18 באפריל 2016

296 NLP with Yoav Goldberg

אנחנו בפודקאסט 296 התאריך הוא ה 13 למרץ ואנחנו מארחים את יואב גולדברג לשיחה על NLP- תחום עיבוד שפה טבעית וחלקו בMachine Learning.
  • 2:24 – NLP – עיבוד שפה טבעית – אלגוריתמים שעובדים על טקסטים אנושיים ומוציאים מידע שימושי מתוך הטקסט.
  • 5:54 – שימושים מעניינים בNLP כגון שימוש GOOGLE בחיפוש – הבנה של כוונת המשתמש והדפים שעליהם מחפשים. האפשרות לשאול את מנוע החיפוש שאלות בשפה טבעית וקבלת התשובות.
  • 9:32- הדגש על הבנת הדומיין בעיבוד שפה – לעומת סירי שעובדת בדומיין מוגבל וקטן יחסית, גוגל עובדת בדומיין מאוד רחב. דוגמא עבור שימוש מדומיין ספציפי – גוגל מאפשרת לקרוא מהמייל אישורי טיסה ולהכניס ליומן זימון לטיסות בתאריכים הנכונים.
  • 13:17- אחד הנושאים שחשוב להבין בNLP הוא קושי הבעיה, למרות התפיסה שזהו מימוש פשוט ולאדם זוהי משימה קלה, המשימה עבור מחשב היא מורכבת. קיימות ספריות בסיסיות לניתוח תחביר וניתוח חלקי דיבר ומעליהן יש לממש את האפליקציה הספציפית (לדוגמא NLTK בפייתון)
  • 17:50 – אין מוצר שמבין עמוקות את הטקסט – יוצאות דופן הינן מערכות הדיאלוג שמנסות להבין את בקשת המשתמש ולמפות שפה טבעית ל"שפת מחשב" ואובייקטים.
  • 19:50 – הקשר בין  Machine Learning ל NLP – הגישה בעבר הייתה כתיבת ותחזוקת חוקים לצורך עיבוד השפה. לפני כעשור נעשה מעבר לעולם הלמידה- Machine Learning – המחשב רואה דוגמאות עם תשובות ולאחר הלמידה יודע לסווג את הדוגמאות וקלטים חדשים.  עדיין – ישנה התערבות ידנית בתהליך הלמידה והגדרת בעיית הסיווג – לדוגמא בעיית סיווג עמודים ברשת לפי נושא.
  • 26:35- היבטי Deep learning בעיבוד שפה – בשנים האחרונות נכנסים אלגוריתמי Deep learning לעולם ה NLP אך הם עדיין לא חזקים.
  • 27:50 – המחקר העכשווי של יואב - תשתיות של עיבוד שפה – לקחת את אבני הבניין של עיבוד השפה ולשפר אותן. רוב המחקר נעשה באנגלית – השפה הנפוצה במוצרים ובמחקר.
  • 32:50- יואב פעיל ב Git ובעבודות האחרונות אבל לדאבונו, מייצר יותר מסמכי LaTex  מאשר קוד -  בפרוייקט קוד נוכחי מייצר ספריית Deep Learning לעיבוד שפה רכיב Core בשפת C++  ומעליו Wrapper בPython
  • 35:35 – טיפ לסיום – לא להשתמש בNLTK – היא ספרייה לימודית בעיקרה ולא לשימוש בProduction. עדיף להשתמש בSpacy.IO דמו :https://sense2vec.spacy.io/?natural_language_processing%7CNOUN.
  • וספריה נוספת שלא הוזכרה Gensim  

תודה רבה לחן סלומון על התקצור! הקובץ זמין כאן להאזנה.