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 (פרטים נוספים בקרוב), מועדון אפורי השיער – לאנשים שמחפשים את השלב הבא לאחר שנפלטו מהתעשיה ופורום החברות הצומחות – עקב החוסרים שקיימים מנסים למצוא מקורות לגיוס ולהכשרה.

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

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 עושים) – אך זהו שינוי ארגוני גדול יותר.

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

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.

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