January 2009 - Posts
למי שלא יודע, המומחה מספר אחד בתחום של Prism (ו Cab) הוא לא אחר מאשר David Platt. חברת ידאג ייבאה בזמנו את David לארץ כדי להעביר סדנה על CAB (הדור הקודם של Prism) והסדנה היתה מוצלחת מאד. דיויד העביר באותה הזדמנות הרצאה לקבוצת המשתמשים על הנושא האהוב עליו Why Software Sucks שהיתה מאד משעשעת. הוא גם התראיין על זה בדה מרקר.
בכל אופן, דיויד החליט להעביר את הסדנה שלו על Prism בתחילת חודש מרץ בפורמט של Online. היתרון של הפורמט הזה הוא שאתה לא צריך לנסוע לחו"ל כדי ללמוד, או לחילופין אני לא צריך לגרור אותו לארץ בשביל הסדנא. נכון שבפורמט של Online אתה לא יכול ללכת לאכול עם המרצה ארוחת צהריים, אבל יש לך אפשרות גם לשאול שאלות, וגם ליצור אינטראקציה, תוך כדי ההרצאה ולאורך הקורס. כך שפרט למגע הפיזי זה כמעט אותו דבר.
אז למי שמעוניין להצטרף לסדנא להלן הפרטים. הסדנא נקראת בשם הארוך Programming Prism, Microsoft's Composite Application Guidance and Composite Application Library, Version 2. פרטים על הסדנא נמצאים בקישור הזה. הסילבוס המפורט נמצא בקישור הזה. ההרשמה בקישור הזה. אבל החלק הכי חשוב הוא שיש אפשרות לקבל הנחה מיוחדת בגלל שאתם מישראל וזה הולך ככה. בהרשמה, במסך הראשון, תכניסו בשדה ה Administrator Only את הקוד הסודי Israel (כן, אני יודע שזה לא מקורי). כתוצאה מזה המערכת תתן לכם הנחה נוספת של 100 דולר על המחיר הרגיל. שימו לב שיש מחיר הנחה מיוחד לכל מי שנרשם בהרשמה המיועדת לציפורים משכימות קום שחוסך לך 200 דולר נוספים אם אתה נרשם עד ה 1/2/09 בערב.
למי שלא יודע מה זה Prism ומה אפשר לעשות איתו להלן קישור. דיויד הוא מי שכתב את הספר על CAB שהוא הגירסא הקודמת של Prism והוא גם חבר בצוות ההיגוי של Prism.
השנה, כמו בשנה שעברה, אני קופץ לארה"ב כדי לבקר כמה לקוחות וכדי להרצות ב SD West 2009. למי שלא יודע מה זה SD West, אז זהו כינוס שמארגנת, בעמק הסיליקון, אותה קבוצה שאחראית על ה Dr. Dobb's Journal והכנס שלהם, הוא הכנס הגדול ביותר בארצות, הברית מבין הכנסים שאינם עוסקים אך ורק בטכנולוגיות מיקרוסופט (כלומר מבין הכנסים שאינם נעשים על ידי מיקרוסופט עצמה, כמו TechED או PDC, או מבין הכנסים שנעשים על ידי גורמי חוץ, ועוסקים אך ורק בטכנולוגיות מיקרוסופוט, כמו VS Live). זה לא שהכינוס הזה מתעלם ממיקרוסופט או משהו כזה, נושאים הקשורים במיקרוסופט מוצגים בכינוס. אבל יש בעולם התכנה והמחשבים נושאים נוספים, שאינם קשורים אך ורק בטכנולוגיות מיקרוסופט.
אני הולך לדבר שם על תחום ההתמחות שלי שהוא Production Debugging ומי שרוצה לראות איך זה נשמע באנגלית, להלן הקישור לעמוד שלי בכינוס. בשנה הקודמת התפרסתי על יותר מדי נושאים, מה שהעמיס אותי מאד. מי שעקב אחר החוויות שלי משם, יכול היה להתרשם שזה לא היה כף גדול. השנה החלטתי להתמקד בתחום אחד ולהנות מהחוויה.
אם מישהו מכם מתוכנן להיות בתחילת חודש מרץ בארה"ב ומתכנן להגיע גם לכינוס הזה, להלן כמה טיפים שיחסכו לכם כסף. קודם כל עד ה 16/1/09 ניתן להירשם בהרשמה המוקדמת לציפורים משכימות קום, ההרשמה הזו תחסוך לכם 400 דולר. בנוסף, מי שיכניס את הקוד הסודי של 9ESPK במקום המתאים, יקבל הנחה נוספת של 100 דולר. אני יודע שלא מקובל אצלנו בארץ לתכנן לטווח כל כך רחוק כמו חודשיים, אבל למי שבכל אופן רוצה לחסוך 500 דולר (חצי כרטיס טיסה בערך) כדאי שיזיז את התחת כבר עכשיו.
הפוסט הזה לא היה מתוכנן. נתקלתי בפוסט של עידו גולדברג עם הכותרת Why NOT to install Windows 7 ופשוט התעצבנתי. התחלתי להוסיף תגובה, וגיליתי שזה יצא כל כך ארוך, שעדיף כבר לכתוב על זה פוסט.
הבעיה העיקרית היא שעידו, כמו רבים אחרים, מפספס לחלוטין את מטרתה של הביתא. ביתא לא נועדה להתקנה במערכות Production ולא להתקנה על מחשבי העבודה של מנהלי IT או של המשתמשים בארגון. מטרתה העיקרית של ביתא גם אינה PR וחומר לעיתונאים. הביתא זה דבר רציני מאד, למי שהתחום המקצועי שלו הוא כתיבת קוד או הטמעת קוד במערכות ההפעלה של מיקרוסופט (ולצורך העניין בכל מערכת הפעלה שהיא).
למנהלי IT חשוב מאד להתקין את הביתא במערכות ה Staging שלהם ובמעבדות ההיתכנות, על מנת לבדוק אם הם נתקלים בבעיות, ואם כן לדווח על זה למיקרוסופט, על מנת שלא יתקלו בבעיות הללו במערכת הסופית. מנהל IT שמחכה עד המוצר הסופי כדי להתחיל את הבדיקות, מועל בחובתו המקצועית למערכת שלו. הוא גם באותה הזדמנות מייקר בצורה משמעותית, את עלויות המעבר שלו למערכת החדשה. אבל זה כבר בעיה של ה CFO ולא שלו.
למפתחים מאד חשוב להתקין את הביתא בסביבת ה QA שלהם, על מנת לבדוק שהתוכנות שלהם לא נתקלות בבעיות, ואם כן לדווח על זה למיקרוסופט, כדי שלא יתקלו בבעיות הללו במערכת הסופית. שימוש בביתא במחלקת ה QA בחלק מהמחשבים, עוזר לגלות בגים ובאותה הזדמנות מגלה טעויות בתכנון ואי מילוי דרישות המפרט של הלוגו. כך שמנהל QA שלא משתמש בביתא כדי לשפר את איכות המוצר שלו, גם כן מועל בחובתו המקצועית כלפי הארגון שלו.
בזמנו הייתי שותף למעבדה שהקימה מיקרוסופט ישראל, על מנת לאפשרת לחברות תכנה ישראליות, לבדוק את המוצר שלהם על ויסטה, לפני שויסטה יצאה לשוק. אלה שבאו למעבדה, יצאו עם מוצר שעבד עם ויסטה ולא נלחם עם ויסטה. היתה לזה השפעה רבה על הקטנת העלויות של ה Help Desk שלהם.
חשוב לציין שהביתא לא נועדה כדי שאנשים יתקינו אותה במקום מערכת הפעלה תקנית, כדי להתפאר אצל החברה ביום שישי, שיש להם את זה בבית. העתונות וחוות הדעת, אם כל הכבוד, הם שיקול משני וקטן, יחסית לצורך הקריטי לאסוף מידע, על קבוצת טסטרים גדולה, עם QA רחב יותר ממוטת הבדיקות של מיקרוסופט. גם אם הביתא תיכשל לחלוטין, היא תהיה הצלחה. למרבה הפרדוקס, ככל שהביתא תיכשל יותר, ככה היא תהיה הצלחה גדולה יותר, שכן הבעיות שיתגלו בביתא כבר לא יופיעו במוצר הסופי.
עידו גם מרבה לדבר על הבעיות של ויסטה ואני לא יודע על מה הוא מדבר. אני עובד כבר הרבה זמן עם ויסטה, ולא סתם עם ויסטה, אלא עם ויסטה 64 ביט. אני יכול להעיד ממקור ראשון, שאצלי אין בעיות. היו כמה בעיות זניחות ועל חלקם דיווחתי בבלוג, אבל בסופו של דבר, אלה היו הרבה פחות בעיות מאשר נתקלתי בהם, כש XP החליף את Win95. חשוב אולי גם לציין, שהרבה מהבעיות שהעיתונות עשתה מהן עניין כה גדול, היו יכולות להימנע, אם האנשים היו קוראים את דרישות המערכת וגם בודקים אותה על החמרה שלהם לפני ההתקנה.
אז למה כל כך התרגזתי ? בגלל השימוש במילים ישועה ומשיח. ויסטה אינה עד כדי כך גרועה, שצריך התערבות אלוהית, בצורה של חלונות 7, על מנת לפתור את הבעיה. את שתי המערכות כתבו בסופי של דבר בני אדם.
כהרגלי בקודש התקנתי את Live Writer על המערכת. הפעם החלטתי להתפרע ולהתקין את הגירסא העברית מה שכמובן הכניס אותי למצב בלתי אפשרי של תפריטים בעברית, וקשיים קוגנטיביים מסוימים בהבנת הנקרא.
למישהו יש מושג מה זה םוספ ךיראת רדגה ? לקח לי זמן לפצח את זה אבל הצלחתי בסופו של דבר. השאר נראה על פניו מוזר אבל תקין מבחינת העברית. המאיית לא כל כך מסכים עם העברית שלי וגם לא מזהה מתי אני באנגלית. והסמן כמו תמיד ב Live Writer נמצא כזה באמצע כך שאתה תמיד צריך לנחש אם אתה באות שלפני או באות שאחרי.
להלן תמונה סתם בשביל לבדוק שזה עובד.
לפי הנאום של סטיב ב CES, מיקרוסופט תאפשר ל 2.5 מליון איש להוריד את הביתא של Windows-7 על בסיס מי שבא ראשון, מקבל. אתר ההורדות מתוכנן להפתח לקהל הרחב ב 9/1/09 בשעה 6 PM PT. תרגום קל לשעון שלנו מדבר על משהו כמו שבת 4 בבוקר לפי שעון ישראל. אז אם אתה יהודי, תצטרך גוי של שבת לצורך העבודה הזו (אלא אם כמובן ניתן להתיחס לזה כעונג שבת ואז הכל בסדר).
כתובת האתר היא כנראה http://www.microsoft.com/windows/windows-7/default.aspx וגם אולי http://technet.microsoft.com/en-us/windows/default.aspx. יש המון דיווחים באינטרנט על בעיות ממשפחת ה 500 כמו Server unavailable או Server too busy בגישה לאתר של W7, מה שמעיד על ביקוש מוקדם גבוה. מנויי MSDN ו Technet אמורים להיות מסוגלים להוריד את החומר כבר עכשיו, מאתרי המנוי שלהם והם מן הסתם לא כלולים במכסת ה 2.5 מיליון.
כמה אזהרות שכדאי לחזור עליהם לכל מי שלא נשרף מספיק פעמים. לא מתקינים ביתא על מכונת Production ולא על מכונה שתהיה לך בעיה רגשית לפרמט אותה ולהתקין מחדש בעת הצורך. זה נכון לכל ביתא ואלפא ולא רק ל W7.
לא שמים על מכונת ביתא חומר קריטי וחומר שאין לך גיבוי שלו. אם אתה מתעקש להשתמש במערכת ביתא על מחשב עבודה, תקפיד על גיבוי מסודר וקבוע של כל החומר האישי למדיה חיצונית.
אני משתמש בפרה ביתא של W7 באופן די קבוע מאז שקיבלתי אותה ב PDC ולא היו לה נפילות. אבל לא הפכתי אותה למכונה הראשית שלי. החל מאמש אני עובד הרבה עם גירסת הביתא החדשה, וגם היא עוד לא נפלה לי. הביצועים של גירסת הביתא משופרים יחסית לגירסת הפרה ביתא. למרות זאת, אני לא מתכנן להתקין את גירסת הביתא על המכונה הראשית שלי לפחות עד שלב ה RTM. זה לא בגלל שאני לא סומך על W7, אלא בגלל שככה צריך לעשות.
דרישות החמרה של W7 צנועות יחסית, 1G זכרון ו 128M כרטיס מסך שתומך ב DirectX 9. זה לא שונה בהרבה מהדרישות של ויסטה (ויסטה רצתה 256 זכרון על כרטיס המסך) אבל אין ספק ש W7 מוציאה יותר מיץ מהמכונה.
היום בשעה 6:15 בבוקר, ממש לפני שהתחלתי לארגן את עצמי לאסוף את Juval ליום האחרון של סדנת הארכיטקטים, קיבלתי את הדואל מאתר connect שדיווח לי שהביתא של W7 זמינה להורדה. בערך מלפני שעה (23:00), אני יכול לדווח לציבור, שיש לי מכונה וירטואלית מלאה מתפקדת ועובדת, של W7, מוכנה לפיתוח ולמחקר על פי המפרט הרגיל שלי למכונות פיתוח.
למי שזה חשוב, אז W7 Ultimate תופסת 2.5 ג'יגה ב ISO שלה. ה WDK שלה תופס בערך 0.6 ג'יגה ב ISO וה SDK תופס בערך 2.8 ג'יגה ב ISO. ההתקנות עצמם לקחו מעט זמן. רוב הזמן הלך על המתנה ל FTM שיסיים את ההורדות.
עדיין יש בעיה עם זה ש W7 לא מזהה את חמרת הרמקול של ה VPC2007 SP1, וגם צריך לתת כתובת סטטית בכרטיס הרשת ל DNS של 192.168.131.254 על מנת שההתחברות לעולם תהיה חלקה (זו בעיה של תכנת ה VPC ולא של W7). אבל פרט לזה, ההתקנות של מערכת ההפעלה וכל סביבות הפיתוח שלה (WDK ו SDK) עברו חלק ועברו גם בדיקות תקינות מלאות.
למי שזה מעניין, זמן התנעה של ה VPC, מלחיצה על התנע ועד מסך Login, הוא כ 60 שניות, וממסך Login לוקח עוד כ 20 שניות לאחר הכנסת הסיסמא, עד למערכת מוכנה לעבודה.
נתתי למכונה הוירטואלית 1G זכרון, וכפי שניתן לראות, יש עדיין קרוב ל 700M פנויים
ברירת המחדל של תמונת הרקע קצת יותר פסטורלית מויסטה, ויש שם אפילו דג שעושה בלוב בלוב.
שימו לב ל Face Lifting שעשו ל Paint ול Word Pad.
היתה כוונה גם לעשות את זה ל Note Pad אבל היה מרד כללי של כל המשתמשים ולבקשת הקהל עצרו את העבודה על Note Pad, לפני שיגרם לכלל המשתמשים נזק בלתי הפיך (לפעמים עודף יצירתיות יכול לגרום לנזק).
חשוב ללחוץ על מקשי המשוב המפוזרים לאורך המערכת ולבקש חזור ובקש "רק לא ריבון", "רק לא ריבון", תשאירו לנו את התפריטים, כדי שמי שכבר מכיר בעל פה איפה נמצא כל דבר, לא יצטרך לחפש שעות איך לעשות את זה עם הריבון. דרך אגב, גם המחשבון עבר התעללות קלה והוא עדיין קצת כחול כתוצאה מזה. אבל הכי חשוב לדעתי זה שלא יפגעו ב Note pad.
ומה שאולי באמת השינוי הכי חשוב ובולט, המפץ הגדול בהתנעה, הפך מעגול למרובע.
יש עוד המון דברים לספר על הביתא הזו, אבל אני עדיין עסוק בסיכום החומר של סדנת הארכיטקטים. ביום האחרן ביצענו תרגול מעשי, על ארכיטקטורה של מערכת אמיתית, שהביאו לניתוח כמה מהמשתתפים בסדנה. היו לי המון תובנות מהתהליך. היה ממש כף לראות שוב, את הטכניקה שנקראת The IDesign Method בפעולה.
קטע קטן של הדיון הטכנולוגי היום עסק בלהיט החדש "דוט נט Service Bus". מובן שההסתכלות בסדנה היתה מאספקט ארכיטקטוני. הסתכלות מהכיוון הארכיטקטוני שונה לחלוטין מהסתכלות מהכיוון הטכנולוגי כפי שהוצגה המערכת ב PDC. אבל Juval סיפר באותה הזדמנות למשתמשים שההרצאה שלו לקבוצת המשתמשים מחר בערב תיכנס לנושא הזה הרבה יותר עמוק מהבחינה הטכנולוגית. ניצלנו את ההזדמנות ומשתתפי הסדנא ביחד עם Juval תרגלו בפועל את אחת מההדגמות הרבות שהוא יבצע בהרצאה לקבוצת המשתמשים (ואני לא אהרוס לכם את ההפתעה ואספר לכם מה עשינו בענניםעם תשתית ה Azure).
זו הזדמנות טובה להזכיר לכל מי שלא יודע, שמחר ב 17:30, יש מפגש מיוחד של חברי קבוצת המשתמשים עם Juval, בנושא Introducing the .NET Service Bus. להלן הקישור לדף ההרשמה לארוע, למי שרוצה להיות ילד טוב ולהודיע שהוא מגיע, ולא להיות ילד רע ולבוא סתם ככה בלי להודיע.
אחת מהדעות המקובלות בתחום הארכיטקטורה, היא שארכיטקט צריך לבצע את הארכיטקטורה בלי כל קשר לטכנולוגיה ספציפית. ורק שהארכיטקטורה גמורה, בוחרים מהי הטכנולוגיה שבה ישתמשו. הדעה של Juval שונה. Juval טוען שהארכיטקט חייב לדעת היטב את הטכנולוגיה ולטכנולוגיה יש השפעה ישירה על התכנון הארכיטקטוני. הלוגיקה מאחורי הטיעון הזה הולכת משני כיוונים. מצד אחד, אין טעם לעשות תכנון ארכיטקטוני, למשהו שכבר קיים כאבן בניין בתשתית הטכנולוגית שאתה משתמש בה. מצד שני, אין טעם לתכנן שימוש בקוביה ארכיטקטונית, אם לא ניתן לממש אותה בטכנולוגיות הקיימות. אני חושב שארכיטקט טוב לא יכול להיות מנותק לחלוטין מהטכנולוגיה, אחרת התכנונים שלו יוצאים מנותקים מהמציאות.
הטענה היותר מעניינת ש Juval העלה, היא שהארכיטקט לא חייב להיות מומחה במרחב הבעיה. הטענה שלו שהפתרונות הארכיטקטונים אגנוסטיים למרחב הבעיה, היא כיוון מחשבה מעניין. האם ארכיטקט שעושה ארכיטקטורה למערכת שעוסקת בביטוח, לא חייב להבין בביטוח ? האם ארכיטקט שעושה מערכת לגביית מיסים, לא צריך להבין במיסים ? מה שמסתתר מאחורי הטענה, זה האבחנה, שבסופו של דבר, בהסתכלות מלמעלה על ה Use Cases, התרגום מה Use Cases לארכיטקטורה, אינו תלוי בפרטים הספציפיים של מרחב הבעיה.
כלומר הארכיטקט לא יכול להיות מנותק מהטכנולוגיה אבל הוא כן יכול להיות מנותק ממרחב הבעיה. מוגש כחומר למחשבה לכל מי שעוסק בארכיטקטורה.
הימים השני והשלישי של הסדנה עוסקים בכיוונים ארכיטקטוניים ואיך הם מתקשרים לטכנולוגיה. את היום השני Juval פתח בניתוח היסטורי מעמיק של הדרך הטכנולוגית הארוכה ל SOA. המסלול של הסקירה של Juval הראה בבירור, שכל פתרון טכנולוגי חדש, בא לשפר בעיות שהיו קימות בטכנולוגיה הקודמת, אבל הציג באותה הזדמנות, אוסף של בעיות חדשות. ארכיטקט צריך להכיר את כל הבעיות הללו, כדי לא ליפול מחדש, בתכנון שלו, אל אותה מלכודת שאחרים כבר נפלו עליה, ולמדו בדרך הקשה, שלא זו הדרך. כי מי שלא לומד מנסיון של אחרים, ילמד את הלקחים על עצמו וזה בזבוז של משאבים.
הטכנולוגיה עברה דרך ארוכה של ניסוי וטעיה החל מהאניגמה וכלה במיחשוב ענן. בתור מי שתפקידו הוא לאתר בעיות במערכות, המפגש המחודש עם כל הטעויות והבעיות שהציגה כל טכנולוגיה, היה בשבילי מעין שעור חזרה והרבה דז'בו, לכל סוגי הבעיות שנתקלתי בהם בפועל אצל לקוחות לאורך השנים.
חשוב אולי לציין, שבהסתכלות שלי, ובחלוקה סטטיסטית, ניתן לחלק את הבעיות שנתקלתי בהם לכמה קבוצות. במקום ראשון תקלות שנובעות בסופו של דבר מתכנון ארכיטקטוני לקוי וזה הרוב. במקום השני תקלות שנובעות משימוש לא נכון בטכנולוגיה (Technology Abuse) שנובעות בעיקר מפערי ידע וחוסר הבנה של כללי המשחק של אותה טכנולוגיה, שזה גם כן משהו ששיך לשלב התכנון. במקום השלישי, תקלות שנובעות מתהליך פיתוח לא תקין, כמו למשל אי ביצוע Code Review או אי ביצוע בדיקות מינימליות נדרשות או אי שימוש ב Coding Standards כמו למשל אלה שמופיעים בצד ימין של האתר של IDesign. לא נתקלתי כמעט לאורך ההיסטוריה האישית שלי, בבעיות שנבעו מהטכנולוגיה עצמה. מה שמחזיר אותנו למנטרה, שטכנולוגיה היא כמעט אף פעם לא הסיבה לכשלון של פרויקט.
היום הראשון של הסדנא מתקרב לסיומו. אנחנו צפויים לסיים לקראת 19:00. מאחר וכל המשתתפים רגילים ממילא להשאר בעבודה עד אמצע הלילה. ההשתתפות בסדנה מהווה עבורם בעצם סוג של חופשה.
הדקות האחרונות של היום הראשון של הסדנא עסקו בין השאר בפסיכולוגיה של ארגונים. המוטיבציה היא שמי שרוצה להיות ארכיטקט, חייב להיות מסוגל למכור את התכנונים שלו למגוון רחב של קהלים. החל מההנהלה הבכירה מלמעלה, דרך עמיתים, וכלה בצוותים שאמורים לממש אותה. תהליך המכירה איננו מסתיים בנקודה אחת, רגע אחד של חוסר השגחה, והארכיטקטורה המבריקה שלך הופכת לחורבה ארכיטקטונית. הכרת הכוחות הפסיכולוגיים המנחים החלטות ארגוניות והחלטות של קבוצות, הם עוד כלי חשוב בארגז הכלים של הארכיטקט.
המקבילה של MSF לנושא הזה, מסתכמת במנטרה Foster Open Communication. תקשורת פתוחה בצוותים והיכולת של כל אחד מהמשתתפים בפרויקט להתבטא בחופשיות קריטית לתהליך ניהול הסיכונים. במחקרים שנערכו על פרויקטים שהתמוטטו מסיבות שונות (רוב מכריע של הפרויקטים בתעשיה שלנו), חברי הצוות ידעו מספיק מוקדם שהפרויקט בדרך להתמוטטות מוחלטת וגם מה אפשר לעשות כדי להציל אותו. אבל שמרו את המידע בבטן ולא הוציאו אותו החוצה. יצירת סביבה פתוחה לתקשורת אינה פשוטה כמו שזה נשמע. זה שאתה אומר לכולם תתבטאו בחופשיות לא בהכרח יגרום להם להיפתח. יש חשיבות עצומה לשאלה אם אתה באמת מאמין בתקשורת פתוחה או שאתה רק מעמיד פנים.
אני מקווה שברור לכולם שאני לא מנסה אפילו לרגע, לעשות Live Blogging מלא של הסדנה של Juval. כמות החומר המועברת בסדנה היא בשני סדרי גודל מעבר ליכולת הכתיבה שלי. אני גם לא מצטט את Juval או מנסה לתמצת אותו. כל מה שאני עושה, זה מנצל את ההזדמנות שיש לי קצת זמן פנוי בסדנה, כדי להעלות כמה נקודות למחשבה, שנובעות מנסיון החיים האישי שלי. מחשבות שמתעוררות כתוצאה מנושא או תת נושא ש Juval דן בו בסדנא.
למשל הדיון שלקח כמה שניות בודדות בסדנא, על מה המטרה העיקרית של Testing. בניגוד למה שאולי קופץ לך לראש, המטרה של Testing אינה להוכיח שהמוצר עובד, אלא לשבור את המוצר ולהוכיח שאינו עובד. למי שיצא לשמוע אי פעם את רועי אושרוב מרצה על TDD, הקטע הזה צריך להישמע מוכר. אני מקוה שלא יפתיע אף אחד מהקוראים לדעת, שגם Juval וגם MSF (ואם זה חשוב למישהו, גם אני) סבורים, ש Testing טוב קריטי להצלחת הפרויקט.
מה שמכניס לדיון המון נושאים שקשורים ל Testing. להלן כמה שאלות למחשבה. כמה טסטרים יש לך על כל מפתח. כל מספר שפחות מיחס של אחד לאחד לפחות, הוא סימן רע לסיכוי ההצלחה של הפרויקט שלך. האם אתה בודק גם את מסמך הדרישות ? האם אתה בודק את התכנון ? האם אתה בודק גם את הארכיטקטורה ? נכון שאלה לא פעולות של כתיבת קוד, אבל טעות שם תעלה יותר ביוקר מטעות בקוד. האם אתה מבצע Code Review ? והאם זה תנאי ל Check In ? אם לא, זה סימן לא טוב לאיכות הקוד שלך. האם לכל קומפוננטה של המערכת יש סביבת בדיקות עצמאית שלה ? האם הבדיקות שלך ממוכנות או ידניות ? אם לא יהיה לך יותר קשה לאתר תקלות בהמשך הדרך. האם אתה יכול להפעיל את הבדיקות גם בסביבת היצור מבלי להפריע לפעילות השוטפת (מה שנקרא תמיכה ב Instrumentation) ? אם לא, זה סימן שאין לך איש IT או Help Desk בצוות. האם המנטרה Quality is non negotiated עומדת למול עיניך כל הזמן, או שאתה מומחה בלעגל פינות. כל השאלות הללו הם שאלות שבאות בכלל מ MSF, וקפצו לי לראש כתגובה לחלק קטן מהדברים ש Juval הזכיר (כפי שכבר אמרתי, הסדנה צפופה מאד במידע).
לכל מי שחושב שכל הדברים שמניתי כאן עולים כסף ולוקחים זמן ? אני יכול להבטיח לו שהוא צודק לחלוטין. אבל מהניסיון שלי בתור שרברב, אם לא תוציא את ההוצאה הזו בשלבים השונים של התכנון הקידוד והבדיקות, אתה תוציא יותר, על איתור הבעיה ותיקונה, כאשר תתקע באינטגרציה או בסביבת הייצור.
היום הראשון של הסדנה מתמקד בתהליך. תהליך נכון הוא הבסיס למעבר ממערכת כאוטית למערכת שינתנת לחיזוי (או בשפה המקצועית מעבר מ CMM 1 ל CMM 2). תהליך הוא חרב פיפיות. לכל מי שיצא לו לעבוד עם נוהל מפתח, או עם כל הוריאנטים של ISO 9000, אני לא צריך לספר, איך בקלות רבה אתה חוטף את הלהב השני ישר בבטן.
אי אפשר לנהל בלי תהליך. גם מאחורי השיטות הכי Agile - ליות הכי משוגעות, מסתתר תהליך מובנה ומסודר. הבעיה עם תהליך, היא שהרבה פעמים, אנשים שוכחים שמטרתו של התהליך היא לעזור בניהול ולא לשמש כמטרה בפני עצמה. כי ברגע שהתהליך הופך להיות המטרה, איבדת את הפרויקט.
הנושא של תהליך הוא אחד מאבני היסוד של MSF, שהוא תחום התמחות שלי. כשמיקרוסופט יצרה את ה Team System, היא לקחה את כל הידע שלה ב MSF 3.0 ודחפה אותו למערכת ה Team System בשבלונות ה MSF שמסופקות עם המוצר. הנושא הזה כואב לי במיוחד, כי שימוש בשבלונה, לא מבטיח את הצלחת הפרויקט. כי מי שעובד עם שבלונות ה MSF של Team System, ולא מבין את התיאוריה של MSF שמסתתרת מאחורי השבלונות. רוב הסיכויים שהתהליך יהפוך אצלו למטרה, במקום לשרת את המטרה. זה טעות שיכולה להיות הרסנית לפרויקט ולצערי נתקלתי בזה בחלק מעבודות השרברבות שלי.
היום החלה סדנת הארכיטקטים של Juval. סדנת הארכיטקטים של Juval מטפלת בתחום שמשפיע הכי הרבה על תעשית התכנה שלנו. בתור אינסטלטור, שנקרא בדרך כלל כדי לתקן מערכות שמתמוטטות. אני יכול להעיד שכמעט כל הנפילות שאני מטפל בהם, נובעות בסופו של דבר מארכיטקטורה לא נכונה. כך שאף אחד לא צריך לשכנע אותי, שתפקידו של הארכיטקט קריטי להצלחת פרויקט תכנה. למעשה צברתי משך השנים שאני עוסק בתחום, המון תובנות ארכיטקטוניות, שבאו מהצד המעשי, של מי שאמור לאתר את ה Root cause of failure בנפילה, ומגיע בסופו של התהליך לתכנון הארכיטקטוני Bottom Up, ולא מהתיאוריה.
יובל התחיל את היום בהסברת המקורות של משבר התכנה, וההבדל בין פיתוח תכנה לבין דסיפלינות הנדסיות אחרות. זה נושא רחב מאד שמתחיל ב"למה גשרים מתמוטטים פחות מתכנה" ומסתיים (איך לא) בכיצד נותנים ל "ארכיטקט" ללא כל השכלה פורמלית ותואר הנדסי רשמי בארכיטקטורה של מערכות תכנה (ואין דבר כזה), לעשות ארכיטקטורה למערכת תכנה.
המטרה לא היתה לקטר על המצב, אלא לתת בסיס וכלים לסטודנטים בקורס, כדי שיבינו מה הם כארכיטקטים, צריכים לעשות עם עצמם ועם הצוותים שהם מנחים, על מנת להפוך את התהליך ליותר Engineering ופחות Science. רק מההרצאה הזו ניתן להוציא כמה עשרות פוסטים אבל למי יש זמן.
למי שעוקב אחר הסאגה שלי בנושא המחשב האישי החדש שלי, שנמשכת כבר הרבה יותר מדי זמן. יש לי בשורה משמחת. יש לי, סוף סוף, מחשב אישי חדש. המחשב הוא ממשפחת ה ThinkPad של Lenovo מדגם T500. זו לא מכונת משחקים ולא מכונה למופרעים. אבל המחשב כולל 4G זכרון מדגם DDR3, דיסק מהיר 7200, יע"מ עם Cache מוגדל, קורא כותב DVD ואפילו Webcam וסוללה עם 9 תאים. המחשב לא כולל קורא טביעת אצבע, כי אני לא מאמין בצעצוע הזה. המחשב גם לא כולל כרטיס מסך משוגע אלא Chipset מובנה. כי הדרישה שלי (למי שזוכר), היתה User Experience Index גדול מ 4 בכל המדדים פרט למשחקים. מסתבר שהכרטיס המובנה הרגיל, מספק את הדרישה. אבל הנקודה הכי חשובה, היא, שהוא בא מותקן מהיצרן, עם ויסטה 64 ביט.
איך הצלחתי סוף סוף לקבל את מה שאני מבקש (כי המפרט שלי כבר מסתובב בשוק די הרבה זמן). פשוט מאד, לקראת הנסיעה שלי ל PDC, הלכתי לרעות בשדות זרים. עשיתי מה שעושה כל אמא פולניה כשהיא מתיאשת, עשיתי את זה בעצמי. גלשתי, לאתר של Lenovo בארצות הברית. תוך עשרים דקות קינפגתי לי את מכונת החלומות שלי. שילמתי בסביבות 1500 דולר. ביקשתי שישלחו לי אותה לידיד שלי בארה"ב, שהביא לי אותה ל PDC. חזרתי איתה לארץ (ואם זה מעניין מישהו, אז גם דיווחתי עליה במכס ושילמתי את המע"מ).
אספתי בשנה האחרונה המון הצעות מחיר. הרבה מפיצים הציעו לי עיסקות קומבינציה של השתלת מוח, למחשב שיש להם במלאי. דהינו שהם יתקינו לי את הויסטה 64 ביט בעצמם, ושהם יחליפו לי את הדיסק לדיסק מהיר ושהן ישדרגו לי את הזכרון כו'. סרבתי לכל ההצעות הללו, בגלל שהתעקשתי שהויסטה 64 ביט תהיה מותקנת מראש על המחשב על ידי היצרן. בהסתכלות השוואתית, כל ההצעות האלה היו גם יותר יקרות בצורה משמעותית, וגם הציעו לי בסופו של דבר, מחשב נחות מבחינת ביצועי חמרה, ממה שרכשתי בסופו של דבר ישירות בארה"ב. חשוב לציין שאני לא קיבלתי הנחה חריגה, קניתי אותו מאתר היצרן, במחיר המחירון ואפילו שילמתי עוד תוספת מחיר של 8% מס, בגלל שהמשלוח נעשה לקליפורניה.
הנסיון הזה עורר בי תהיות, לגבי גובה הקופון אותו גוזרים עלינו מפיצי המחשבים הניידים בארץ. יש לי גם כמה תהיות לגבי איכות השירות אותו אנחנו מקבלים בארץ, למרות שאנחנו משלמים יותר.
אני יודע שמה שעשיתי לא מתאים לכל אחד, אבל אם אתה ממילא נוסע לארה"ב ואתה צריך נייד חדש, אתה מוזמן ללמוד מהנסיון האישי שלי.