#Arraylist and List in C

שלום לכם,

בטח שאלתם את עצמכם לפחות פעם אחת, באיזה Collection עדיף להשתמש?
אז ככה, <List<T הוא generic class. הוא תומך בשמירת אובייקטים מטיפוס מסוים מבלי לבצע המרה מ_ או ל_ object (ב Arraylist הייתה מתווספת תקורה של boxing/unboxing, ולכן <List<T יעיל יותר מבחינת ביצועים).
<List<T מממש את <IEnumreable<T ובכך ניתן לשימוש יעיל ללא המרות כלשהן ב LINQ.
Arraylist שייך לטרום עידן ה generics ב #C, כמעט לפני עשור, עוד לפני שהושק IPhone first generation.
כיום, לא נראה שיש באמת סיבה מוצדקת להשתמש ב Arraylist ב Net Frameworks. מתקדמים, אלא אם כן נרצה להתממשק ל API ישן.
דבר נוסף, השימוש ב Strongly typed objects ב <List<T, חוסך לנו התעסקות עם casting errors ב runtime.

תהנו!

מה חדש ב Net Framework 4.5.? חלק 1.

שלום לכם,

גרסת Net Framework 4.5. שוחררה באופן רשמי בתאריך ה 15/08/2012. הגרסה כוללת מספר Feature-ים ושיפורים חדשים.
Net Framework 4.5. נתמכת החל מ Windows Vista והיא עושה שימוש ב CLR 4.0.

בפוסט זה אסקור את החידושים בנושאים הבאים:
- GC.
- Asynchronous Programming.
- Parallel Computing.

בחלק שני אסקור את החידושים בנושאים הבאים:
- Asp .Net 4.5.
- EF 5.0.
- ADO .Net.
- WCF.
- WPF.

GC Background Cleanup:

ב Net. Framework 4.0, ה GC התנהג בצורה מעט בעייתית כך שבזמן ביצוע ניקוי האובייקטים, כל ה Thread-ים של האפליקציה הושהו וכך אותה אפליקציה איבדה חלק ניכר מהתגובתיות שלה בטווח זמן זה.
על מנת להתגבר על הבעיה, התווסף Feature חדש הנקרא Server GC.

כעת Net Framework 4.5. יודעת להקצות עוד Thread אשר מטפל ברקע בניקוי Generation 2 ומצטרף למאמץ המלחמתי של ה Thread המרכזי של ה GC. ובכלל, ככל שיהיו יותר ליבות פנויות במכונה, כך יתאים עצמו המנגנון וידאג לייצר עוד Thread-ים ויפנה אותם לטפל ברקע בניקוי ובכך מאפשר לנו לשלב יכולות של Scalability באפליקציה. כמובן שככל שיהיו לנו יותר ליבות פנויות, תגובתיות האפליקציה תוכל להשתפר. אגב, כל הטוב הזה מגיע ללא צורך בשינוי קוד קיים, אלא רק שינוי הגדרה בקובץ ה App.Config:

<configuration>

   <runtime>

      <gcServer enabled="true"/>

   </runtime>

</configuration> 

2GB Arrays:

Net Framework 4.5. מאפשרת שימוש במערכים הגדולים מ 2GB על גבי פלטפורמות של 64bit.
ללא כל תלות בכמות זיכרון ה RAM הפנוי שלנו במערכת, נוצרה לנו הרבה פעמים בעיה בשימוש במערכים מאוד גדולים ובד"כ היינו מקבלים System.OutOfMemoryException.
כעת, ע"י שינוי הגדרה בקובץ ה App.Config, ניתן לשלוט בהתנהגות ה GC בכל הקשור לאובייקטים אלו:

<configuration>

   <runtime>

      <gcAllowVeryLargeObjects enabled="true"/>

   </runtime>

</configuration> 

Regex Timeout:

Net Framework 4.5. מציגה לנו constructor חדש עבור המחלקה:
System.Text.RegularExpressions.Regex המקבל כפרמטר TimeSpan כ Timeout עבור ביצוע פעולת החישוב של ה Regular Expression.
אם ביצוע הפעולה אורכת יותר זמן מאשר ה Timeout המוקצה לה, יזרק Exception מסוג RegexMatchTimeoutException.
אם לא הוגדר Timeout, לא תהיה הגבלת זמן עבור ביצוע הפעולה.

Asynchronous Programming:

Async ו Await הם שני Keywords אשר מאפשרים לנו ליישם תכנות אסינכרוני בעזרת גישה חדשה.
בואו נביט בקוד הבא:

public async void RunItAsync() 

{ 

// let's wait asynchronously for fetching x & y. 

var x = FetchX(); 

var y = FetchY(); 

await Task.WhenAll(x, y); 

// The Remainder. 

Print(x, y);

}

Async ו Await הם צמד חמד, לא ניתן להשתמש רק באחד מהם. הגדרת מתודה ב Async לא משנה דבר באופן הריצה שלה (אשר מתבצע בצורה סינכרונית) עד אשר אנו פוגשים ב Await או כאשר נזרק Exception.
המילה Await מסמנת את הנקודה אשר בה נמתין עד לסיום ביצוע הפעילות האסינכרונית של המתודה הנוכחית. בזמן ההמתנה המתודה הנוכחית מושהית והשליטה חוזרת למתודה הקוראת. בסיום הפעילות האסינכרונית יושלם החלק שנותר מהמתודה.

שימוש ב Feature יכול לאפשר לנו ביצוע פעולות I/O ללא חסימת ה Main Thread של האפליקציה. כאשר מדובר ב UI הדבר מהווה יתרון עצום בכך שאנו מאפשרים המשך עבודה תקינה של המשתמש לצד המשך ביצוע פעילויות ברקע, אך גם מהווה יתרון בכל הקשור ל Server Side code אשר מורץ צורה מקבילית וע"י כך יגרום לשיפור בביצועי האפליקציה.

Parallel Computing:

Net Framework 4.0. ו Visual Studio 2010 הציגו מגוון יכולות תמיכה בתכנות מקבילי כגון TPL ו PLINQ ועוד. גרסת Net Framework 4.5. הרחיבה יכולות אלה בצורה די משמעותית:

TPL:
שיפור דרמטי של עשרות אחוזים בביצועי ספריית ה TPL ללא כל צורך בשינוי קוד קיים או ביצוע build לקוד, רק מעצם המעבר ל Net Framework. החדש.
המחלקה Task הפכה להיות Light Weight, בכך שנבנתה מחדש. שדות מסוימים של Task אשר אליהם לא ניגשים אופן תדיר הועברו למחלקה Task.ContingentProperties אשר כבר בתכנון הראשוני ב Net Framework 4.0. נוצרה על מנת להכיל שדות מידע פחות פופולרים של Task ובכך לצמצם את השימוש בזכרון.
והמספרים מדברים בעד עצמם: שיפור ניכר של בין 15% ל 100% בעת יצירת Task,
יצירת <Task<TResult, שימוש בפקודות כגון Task.WaitAll ו Task.WaitAny ועוד.

PLINQ:
גם בנושא זה הושקעו מאמצים רבים על מנת להביא לשיפור בביצועים כך שמשפטי LINQ יורצו ביעילות באופן מקבילי ובצורה אוטומוטית. נפתרו בעיות של חבלי לידה שהתרחשו ב Net Framework 4.0., כאלה שגרמו להרצת משפטי LINQ בטור ולא במקביל.

זהו לעת עתה,

להתקראות בחלק השני :-)

יניב

.Scrum Forrest, scrum

שלום רב,

תגידו, מה העניין הזה עם scrum? מה ההתלהבות של כולם, ומה היה רע עד עכשיו? למה לשנות נהלי עבודה של צוותי פיתוח ובדיקות אשר לא באמת מבינים את הצורך בשינוי. האם באמת התנהלנו כל כך לא יעיל עד כה? והאם כל זה באמת שווה את המאמץ?

הרבה שאלות, הרבה תהיות ושימו לב, היום זה יום המזל שלכם, יש לי את הספר לכל שאלה תשובה (מאת יצחק לבנון).

הרומן שלי עם scrum התחיל לפני כשנתיים, זו הייתה אהבה ממבט ראשון. שמתי לב לקבוצת פיתוח מקבילה בארגון בו אני עובד אשר נפגשת בעקביות מדי בוקר ומשוחחת, כל אחד בתורו.
המפגש הזה היה נראה לי מעט טרחני, מאולץ ומעייף, אך ככל שחלף הזמן הבנתי את הכח הגדול של פגישה יומית ועוד הרבה מעבר לכך.

מעט עובדות, scrum היא מתודולוגיה זריזה לניהול של פיתוח תוכנה. המושג לקוח מעולם הרוגבי, ומציין את התכנסות השחקנים שעל המגרש לפני כל התחלה מחדש של המשחק  לאחר שהכדור יוצא אל מעבר לקוים.

השיטה..

הרעיון הוא להכשיר קבוצה של מפתחים ובודקים, אשר תהיה אחראית על תכנון, פיתוח ובדיקת הרכיבים החדשים (או שינוי ותיקון הקיימים) של המערכת. מול הקבוצה עומד מנהל המוצר (Product Owner) הרלוונטי אשר אחראי על הגדרת הדרישות ואישור התוצרים המוגמרים לאחר ביצוע. ה Scrum Master הוא אותו גורם שאחראי על הטמעת השיטה ועל ההתמדה בה וגם על הסרת מכשולים מדרכו של הצוות אל עבר יעדיו. 
Feature נקרא User Story וניתן להבין מהשם כמה השיטה היא User Oriented. ה Product Backlog הוא הסל הוירטואלי, בו מאוחסנים כל ה User Stories אשר בקנה ופוטנציאליים להיכנס אל אחד ה Sprints הבאים.
מה זה Sprint?
הפיתוח יתקיים ב Cycles קצרים (Sprints) באופן יחסי (בין מספר ימים למספר שבועות) כך שבסיום כל Sprint יעלו לאויר אותם Features אשר הוגדרו ותוכננו מראש לאותו Sprint (הם נכנסו בעצם ל Sprint Backlog) בפגישת ה Planning אשר מתקיימת לפני תחילת ה Sprint.
על הצוות להעריך את המאמץ הנדרש עבור כל Feature ברמת דיוק של בין מספר שעות עד מספר בודד של ימים.
בסיום כל Sprint תתקיים פגישת Retrospective שהיא מעין פגישת הפקת לקחים של ה Sprint האחרון. 

היתרונות:

1. שליטה ומעקב הדוקים יותר אחר המפתחים והבודקים (הסוף לשאלה: תגיד לי בבקשה, על מה בדיוק אתה עובד עכשיו? רמז, לא באמת..).
2. יחידות עבודה קצרות הופכות להיות "טסטביליות" הרבה יותר.
3. האפשרות לג'נגל בין מפתחים, בודקים ויחידות עבודה בקלות יחסית. צוות מגובש יותר, בו מתקיימת הפרייה מקצועית הדדית, אשר מידת הידע של מפתחיו/בודקיו די מאוזנת, יצליח לעבוד בצורה יעילה יותר ולהתקדם אל עבר יעדיו.
4. האפשרות לנהל בקרות קוד בצורה צוותית הדדית בצורה מהירה יחסית.
5. הסוף לגאנט? שווה את הכל, לא? במקום להשתעבד לדיווחים ותכנונים שככל הנראה ישתנו לנו מהר מאוד, נגדיר לנו תכנית למספר שבועות בלבד. זה האופק היחידי שלנו ונתרכז רק בו.

באופן כללי ה Sprint נותן לנו את היכולת להיות גמישים לשינויים. כאשר דרישה משתנה לאחר הגדרתה, הרבה יותר קל לנו לשנות את תכנון האב כאשר הראייה היא תכנון ל short run.

אבל, בעצם זאת חכמה די קטנה לדקלם את הנתונים והעובדות היבשות ולכן אני רוצה להניח כמה יחידות מחשבה גם על הצד השני של המאזניים, אז שימו לב, להלן כמה נקודות מוקש:

1. הטמעה. על מנת שנוכל לרוץ עם השיטה החדשה בצורה כמה שיותר משוייפת וחלקה, צריך לדאוג לכך שחברי הצוות יכירו היטב את עקרונותיה. על נושא זה אחראי בין היתר ה scrum master. נקיטת פעולות העשרה והכוונה בנושא ה scrum יעזרו בהמשך לחיבור הצוות לנהלים החדשים.
2. רוח גבית. אוקיי, חשבנו, שקלנו ובחרנו לעבור ל scrum, אבל מה אם הארגון/לקוח/כל בעל עניין שקשור אליי לא כל כך מתלהב מהרעיון. במצבים פוטנציאלים כאלה, שווה לנהל מספר פגישות מקדימות עם בעלי העניין הרלוונטים, להסביר את המוטיבציה והיעדים וכל זאת על מנת שלא יערימו קשיים בהמשך ויטילו ספקות בנושא. עדיף לצאת לדרך חדשה עם כל הכוחות כולם.
3. שיתוף פעולה של הצוות (בין חבריו ומול השיטה). שיטה חדשה, גישה שונה, הרבה יותר אנרגיות נדרשות, הרבה יותר שקיפות נוצרת, תאריך היעד לסיום ה Sprint כל מספר שבועות מגיע כמו שעון שוויצרי, ותכל'ס? למי נהיה קשה יותר ולמי נהיה קל יותר? רמז, לצוות נהיה קשה יותר, אינטנסיבי יותר וככל הנראה, הולך להישאר לו הרבה פחות זמן ל YNET מבעבר. אז איך משכנעים את הצוות שזה דווקא טוב לו? באמת לא תמיד קל, אבל תנו לי לתקוף את הנושא מזוית אחרת ולקחת אתכם לדוגמא של צוות אג'ילי מספרד: ברצלונה (ההיא) של פפ גווארדיולה. כשפפ הגיע הוא עשה מהלך גאוני - בנה תלכיד של שחקנים מרובי כשרון ואינטיליגנטים ונטולי אגו, הוא חיפש את ה typecast הזה בכל מקום על כדור הארץ, מכיוון שהאמין שזהו הבסיס להטמעת כל שיטה חדשה ויישומה ב long run. אז לאחר שסיים עם ניקוי האורוות, הוא פנה להטמעת שיטתו (טיקי-טאקה כמובן) עם המון סבלנות. ולמרות שעדיין מהנדס תוכנה חזק מרוויח מעט פחות משחקני הספסל של בארסה ,ניתן לעשות הקבלות בין הצוותים והשיטות. צוות אג'ילי יעיל וטוב, לא יכול להכיל יותר מדי אגו, ההיפך, נדרשת פה עזרה הדדית ושיתוף פעולה. נדרשת פה גם המון סבלנות של מנהלי הפרוייקט בכל הקשור לעקומת הלימוד וההתקדמות. תהליכים אלה אורכים זמן, אבל ככל שהצוות יהיה מגובש יותר, איכותי יותר ומקצועי יותר כך יגברו הסיכויים שהשיטה תיושם בצורה טובה יותר. לצערי אני מחזיק בדיעה ש scrum לא מתאים לכל אחד, הוא באמת דורש יותר מהתוכניתן/בודק, אל גם נותן הרבה יותר (מה בדיוק?? התשובה בסעיף הבא). 
4. צוות איכותי. אין מה לעשות, פפ לא טעה. צריך אינטיליגנציה גבוהה על מנת ליישם שיטות עבודה מתקדמות. איך שאני תופס את זה, הצוות האג'ילי צריך לעבוד בצורה די מטריציונית, כאשר חבילות הפיתוח עלולות לעבור ממפתח אחד למשנהו בעקבות אילוצים שונים, כנ"ל לגבי בודק התוכנה - הוא צריך להכיר את התמונה הגדולה, כל צוות צריך, אי אפשר יהיה להמשיך ולהתבונן במוצר מנקודת מבט צרה יותר ובכדי לתמוך בשיטת עבודה כזאת, על חברי הצוות להיות באמת אינטיליגנטים יותר, טכנולוגיים יותר, נחושים יותר, עם חשיבה/הבנה עסקית גבוהה יותר. הרי הרעיון הוא שהצוות ינהל את עצמו, יקבל החלטות בעצמו, עם המון אחריות לגבי המוצר ולגבי תוצריו ולמה? זה כל העניין: כי אין יותר את מי להאשים! הצוות הוא הכל ולכן מי שרצה מתנות על העבודה הקשה הנה קיבל, הסיפוק האדיר של כל אחד מחברי הצוות, בכל צעד בכל check-in ובכל Feature שתוכנן פותח ונבדק על ידי אותה קבוצה (מופלאה כבר אמרנו?). אותי זה היה מספק, מה איתכם?

אל דאגה, לא שכחתי את מפתח/בודק התוכנה הוותיק, השחוק, אשר ממש לא מבין את המוטיבציה לשינוי, וככל הנראה גם לא מבין מהי מוטיבציה כלל.

אז מה היה כל כך רע?

1. רפיון. דווקא המודל של מפל המים מתאים לאותו מפתח שחוק כמו כפפה ליד. גרסאות לטווח רחוק, קצת בירוקרטיה בכל הקשור לדרישות פיתוח, הארכות זמנים מופרכות, מעט הסתנכרנות מול Facebook ובעיקר שמירה על סטאטוס קוו.
2. ידע מקומי (או חיבוק הדוב). מי מאיתנו לא מכיר את העניין הזה? לכל מפתח/בודק יש מספר נושאים תחת אחריותו והדבר האחרון שהוא רוצה הוא שמישהו אחר יפשפש לו שם בקוד/כל דבר אחר. מי יודע? אולי מישהו אחר יעשה דברים מהר/טוב יותר..
3. התמונה הגדולה (או תסמונת הראש הקטן). במצב בו כל אחד מחברי הצוות אחראי על נושא מסוים, ניתן להבחין שלרוב חברי הצוות ראייה מאוד צרה ביחס למוצר, למה? אולי מפני שהוא היה עסוק מדי בחיבוקי דובים ופחות היה עירני לסובב אותו מבחינה טכנולוגית/עסקית.

בכל אופן, בכל שיטה יש יתרונות וחסרונות ולהוביל שינוי זה אף פעם לא דבר פשוט, אך לי נראה שבתקופתנו הדינמית ומרובת האתגרים, אנו נדרשים להיות יעילים, זריזים וגמישים לשינויים ככל האפשר ורגע לפני שאני חותם את הפוסט, ברור לי שלא תמיד אפשר להתאים את השיטה לפרוייקט וכמו שכבר רשמתי, לא כל איש צוות ירגיש בנוח עם scrum וגם אם כן, התנהלות בקצב גבוה לאורך זמן רב אכן שוחקת. בכל אופן, בין אם החלטתם להמשיך לחבק דובים או בין אם השתכנעתם להתחיל לחבק את חבריכם לצוות, ההחלטה היא רק שלכם :-)

ולסיום מתנת פרידה קטנה, הנה סרטון (לינק) ממש מוצלח בנושא scrum.

תודה,

יניב

X & Y

תאוריית ה x וה y של דאגלס מקגרגור משנות השישים של המאה ה 20, היא תאורייה פשוטה, שאני באופן אישי מאוד מתחבר לרעיון המרכזי שבה.

דאגלס טען שארגונים נוטים לאמץ אחת משתי הנחות יסוד עבור כל עובד. הוא סיווג את ההנחות בצורה הבאה:

1. תאוריית X.

העובד חושש לקחת אחריות, אינו שאפתן, מונע מפחד מעונש, ובנוסף יעדיף להתאמץ כמה שפחות. על מנת להגדיל את רווחי הארגון יש להדק את המעקב סביבו, ולחלק לו הוראות ברורות בכל שלב.

2. תאוריית Y.

העובד מתאמץ ומשקיע בנושאים הקשורים לעבודה ממש כפי שהוא מתאמץ בנושאים הקשורים לפנאי שלו. בנוסף הוא מחפש אחריות וגם מפעיל דמיון ומפגין יצירתיות

על מנת להגדיל את רווחי הארגון יש לעודד את היצירתיות ואת חופש הפעולה המקצועי שלו, כך ניצור נאמנות הדדית.

OK, נכון, כולנו או רובנו (חוץ ממני כמובן) נוטים לתייג ולסווג אנשים בחיי היום יום ובאמת כמנהל, תמיד ניתן למצוא את העובד שמחפש אחריות ואת זה אשר בורח ממנה כמו מאש, את זה שמסתובב כבוי ורק ממתין לצלצול הגואל, ואת זה שמהלך דבוק תשוקה במסדרונות, ורק ממתין לעוד הזדמנות על מנת להוכיח את עצמו.

נכון, יש גם גוונים של אפור, כלומר עובדים שהם איפשהו באמצע, אבל התאורייה לא מתמקדת בסוגי העובדים אלא בגישה של הארגון כלפיהם.

אגב, כשאני חושב על זה, תאוריית ה Y  ממש מזכירה לי כהורה את שיטת אדלר, שעיקרה: עידוד הילדים וחיזוק בטחונם, התמקדות בנקודות החיוביות ולא בשליליות, תוצאה הגיונית הנובעת מהתנהגויות מסויימות. מה דעתכם?

עד כאן הגישות, אך למה הן עלולות לגרום?

האם אני כמנהל שתייג עובד מסויים ע"פ תאוריית ה X כעצלן ומקטין ראש סדרתי בעצם עזרתי למפלצת לצאת מהארון (תיאור מעט בעייתי..) וסתמתי את הגולל לגבי שינוי רכיבים באישיותו. בכך שניהלתי מעקב הדוק יותר, ולא איפשרתי לו לסטות מהנתיב, הצלחתי לעמוד ביעדים, אך נכשלתי כמנהל במספר סעיפים חמורים כגון עצירת התפתחותו, דיכוי שאפתנותו ובחבלה בתהליך קבלת ההחלטותיו, וחמור לא פחות לדעתי, השחטתי זמן יקר שלי שיכול היה להיות מנותב לקידום נושאים חשובים אחרים.

בשורה תחתונה, If you love someone set him free, אז חבר'ה, מנהלים יקרים, הורים מותשים, שחררו! תייגתם? מילא! אבל תנו קצת קרדיט גם ל X-ים, ומי יודע, אולי יום אחד תופתעו לטובה.

טוב, אולי חוץ מה X הזה..

ניפגש בהמשך.

מערכה ראשונה, תמונה ראשונה

ברוכים הבאים!

שמי יניב ואני מתכוון להעלות לכאן כל מיני מחשבות שמתרוצצות מדי פעם במוחי בנושאי פיתוח וניהול תוכנה. את שאר המחשבות כרגע אשאיר אצלי עד להודעה חדשה.
בכל אופן, אני מאחל לעצמי השראת כתיבה ולכם - חוויה נעימה ומקצועית.

אז תהיו בסביבה,
יניב