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

בכלל ל Visual Studio יש תכונה, שאותה הוא ירש עוד מימי ה Visual Basic העליזים, להסתיר מהמתכנת את העולם האמיתי ולתת לו עולם סטרילי ויפה שבו החיים ורודים והבעיות נפתרות מאליהם. ומילא Visula Studio, בואו נדבר לרגע על האמא הפולניה האולטימטיבית.

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

מהבחינה הזו ה CLR הוא האמא הפולניה הקלאסית. כאשר ה CLR נתקל בארוע לא מוסבר, בואו ונאמר למשל שהוא חוטף פסיקה לא מטופלת שמגיעה מאיזה שהיא תת קומפוננטה כמו למשל רכיב COM, ocx, Remoting, או איזה שהיא חולירע אחרת. כל מה שה CLR יודיע לך (וזה עוד במקרה הטוב) זה משהו אנמי בנוסח "הי, היתה איזו שהיא בעיה קלה וטיפלתי בה". שלא לדבר על זה שבדרך, ה CLR ידאג לנקות באגרסיביות כל שריד לאותה בעיה, ועכשיו לך ותחפש את החברים שלך.

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

בדרך כלל יוצא לי לטוס בלילה לארה"ב. הפעם המראתי על ה 007 של אלעל ב 9:40 בבוקר לניויורק. זה שינוי מרענן לישון בלילה כמו בן אדם, לקום בבוקר, וללכת ליום עבודה, מול המחשב האישי, כאשר אתה יושב על מושב במטוס, במקום במשרד. יש יתרונות לטוס ביום. אז ישבתי וניתחתי Dump – ים ובאיזה שהוא שלב פתחתי את ה Live Writer לכתוב פוסט לבלוג, וגיליתי שם פוסט ישן, על ארוע קבוצת המשתמשים עם  Juval על תפקידו של הארכיטקט, שחיכה להעלאת השקפים לאתר של מיקרוסופט, על מנת שאפרסם אותו.

אני יודע שעבר מאז מפגש קבוצת המשתמשים ב 30/6/2010 כמה חודשים, אבל החומר עדיין רלונטי ומוטב מאוחר מאשר אף פעם. כדאי לציין בהזדמנות זו שאני נוהג להודיע מספק זמן מראש על ארועים שקשורים Juval, הן בבלוג שלי וגם ב LinkedIn, וב FaceBook. כך שמי שמפספס מבצעים וארועים של Juval, שלא יבוא בטענות אלי. אז הנה מה שכתבתי בסוף יוני (עם תוספת בסוף).

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

השקף הראשון בא להזהיר את כל מי שהגיע, שלא יהיו בהרצאה הזו הדגמות קוד, ולא ידברו שם על טכנולוגיה. ולמי שלא יכול לבוא להרצאה בלי לראות שורת קוד אחת, נתן Juval שקף אחד, שמרח על פני מסך שלם את קטע הקוד ; { }.

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

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

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

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

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

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

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

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

לכל מי שרוצה לבחור בקריירה של ארכיטקט, יש לי בשורה משמחת. Juval מבקר אותנו שוב בסוף דצמבר כדי להעביר את סדנת ה Architect’s Master Class היחודית שלו. שההרצאה שהוא העביר בקבוצת המשתמשים היא חלק קטן מהחומר שאותו הוא מעביר בסדנה. מי שמעוניין להשתתף בסדנא, מוזמן לשלוח דואל לסיגל מייד. יש לנו כבר חצי כיתה מלאה שחלק ממנה ניצל את התעריפים המיוחדים של ה Early Bird, כדי לקבל מחיר הנחה מיוחד. מאחר ויש עוד כמה ימים עד לגמר ה Earl-Bird, מי שיזדרז, עוד יוכל להספיק. זו גם הזדמנות לבקש מסיגל להצטרף לרשימת התפוצה שלנו, כדי שלא תפספסו את הארוע המעניין הבא.

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

כמו בשנה שעברה, גם השנה נתבקשתי להרצות בכנס על נושא שיפור ביצועים, שנערך אי שם. השנה יצא לי לדבר על שני נושאים. הנושא הראשון עסק במדידת ביצועים של יישום באמצעות ה Profiler החדש של Visual Studio 2010 והנושא השני עסק בנושא הכנת היישום שלך לסביבת הייצור.

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

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

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

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

אז לאן אתה רוצה להגיע בביצועים של המערכת ? מה ? אתה רוצה לומר לי שזה לא מופיע כדרישה מכומתת ומוגדרת היטב במסמכי האיפיון של המערכת ? אהה…

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

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

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

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

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

יש כמובן יכולת דגימה עם Sampeling ויכולת איסוף מידע באמצעות Instrumentation (שמשתמש כמובן ב ETW, למי שיודע מה זה). לכל אחת משיטת הדגימה הללו יש את היתרונות והחסרונות שלה, שחשוב להבין אותם היטב, לפני שמשתמשים בכלי כדי למדוד משהו.

יש יכולת מדידה גם ב Native וגם ב Managed. יש תמיכה מלאה גם ב 64 ביט וגם ב 32 ביט. יש גם תמיכה מלאה במדידת השפעה של ריבוי ליבות במערכות עם מרובות נימים. יש יכולת ספציפית לעקוב אחר אורך חיים והתנהגות של אוביקטי דוט נט בזכרון. ומה שהכי מעניין, זה יכולת להכליל באיסוף המידע את הפניות של התכנה לשכבות אחרות, כמו למשל קריאות של מסד נתונים, ובכך לאתר צווארי בקבוק בגישה למסד הנתונים. וכמובן איסוף של מוני ה CPU וגם Performance Counters עם טריגרים והכל.

את כל האיסוף אתה יכול לבצע גם באמצעות Scripts ללא הפעלה של ה Visual Studio GUI מה שפותח אפשרויות מענינות של שימוש אוטומטי בכלי לאחר כל Build. ומאחר שאתה יכול להשוות בין מדידות שונות, קל נורא לדעת די מהר עם ה Build הנוכחי טוב יותר או רע יותר מה Build הקודם מבחינת הביצועים.

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

בקיצור פגז של כלי.

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

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

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