GadiM - Gad J. Meir
www.idag.co.il

מפגש קבוצת משתמשי VmWare במלון שרתון בתל אביב

2012-02-04T20:56:25Z

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

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

בכניסה לארוע התמקמו כמה גופים שמספקים מוצרים נלווים ו/או שרותים נלווים למוצרי VmWare כמו Veeam ו HP כאשר מי ששילם על האוכל הוא ספונסר הזהב של הארוע, Hitachi Data Systems, שגם קיבל חצי שעה הרצאה בסוף היום.

את הארוע פתח ברק קורן שהוא הראש הנבחר של קבוצת המשתמשים. ולאחר כמה מילות ברכה הזמין את דרג הניהול הבכיר של VmWare בארץ שאמר כמה מילים קצרות ומיד הזמין לבמה את אורח הכבוד של הארוע, דוקטור Stephen Alan Herrod ה CTO וגם ה SVP R&D של VmWare.

סטיב כיסה הרבה נושאים מענינים ולמעשה רק בשביל ההרצאה שלו היה שווה לי להגיע. כמה פנינים ששלפתי מההרצאה שלו (לאו דווקא לפי סדר החשיבות). יש ל VmWare צוות של 4,00 מהנדסים. הם עוסקים לא רק בוירטואליזציה, חצי מהכוח עוסק בתחום העננים (בעיקר הענן הפרטי). מעל 60 אחוז מהשרתים בעולם רצים על תשתית וירטואלית של VmWare. כל 6 שניות נולדת מכונה וירטואלית על התשתית שלהם וכל 5 שניות מכונה וירטואלת עוברת משרת לשרת עם vMotion (בערך כמו כמות המטוסים שזזה ממקום למקום בעולם) עד כאן שעשועים. הגירסה החדשה של התשתיות (גירסה 5) תומכת ב 32 CPU – ים, טרה (טרה!!) זכרון, יותר מ 36 כרטיסי רשת ומליון IOPS (ואאוו!).

בשולי הדברים הוזכר משהו, שלפי דעתי מיתפספס לרוב אלה שעוסקים בעולם הוירטואליזציה. יש כאן שינוי פרדיגמה לגבי הדרך שבה אתה מתכנן יישומים ומערכות. להיות ארכיטקט יישומי בעולם של וירטואליזציה, נותן מימד שונה לגמרי למושג של תכנון יישומי Enterprise. קוביה בתכנון האכיטקטוני יכולה להיות לא רק Service אלא מכונה וירטואלית שלמה שעושה פונקציה יעודית. ואם Juval אומר ש Every Class is a Service מה דעתכם על Every Class is a VM ? רמז לזה ניתן לראות בחלק העליון של המשולש שמראה "תשתיות" שזמינות לשימוש דהינו Frameware as a service (עוד ראשי תיבות למשפחה, FaaS).

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

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

ניהול של מרכז מחשבים עם כמה מאות/אלפים של מכונות וירטואליות שחלקם אצלך וחלקם בענן דורש כלי ניהול מתאימים הוצג ה VCOps לניהול בענן הוצגו מבטי מנהלים עם Dash Board ותצוגות והקונספט של יצירת Virtual Data Center שהם Private ו/או Public ו/או Hibrid עם רשימת שותפי ענן (כן, גם בזק בינלאומי ו Triple Cloud היו על השקף כשותפי ענן)

הוצגה מגמה שאופינית לארה"ב, שבה מחלקות IT מתחילות להיות מרכזי רווח והופכות לספקי שרות בענן עם דוגמא של בית חולים רב סניפי, שמערך מיחשוב חדרי המיון שלו היה כל כך טוב, שמתחרים ביקשו להתחבר אליו (נורא אמריקאי) הוצגו כמה חידושים כמו למשל VXLAN. דובר על ה Cloud Foundry שזו פלטפורמת חישובי ענן Open Source. שימו לב שיש שניים כאלה, יש Org ויש COM וכל הקוד זמין ב GitHub. הוצג פתרון מנוהל IT לשרות בנוסח Drop Box באמצעות Project octepus. מסתבר שהשאיפה של ה IT להתעלל במשתמשים שלהם ולהגביל אותם בכל צעד היא דבר גלובלי ואינה מאפינת רק את ארצנו הקטנה.

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

לאחר סטיב עלה לבמה אביב וייס שדיבר על תפעול עם vCenter. ואין עושים Monitoring ו Optimization ו Resource Management. כפי שכבר ציינתי, ניהול מושכל זה אולי החלק החשוב ביותר במערכת שכוללת הרבה מכונות וירטואליות ואוטומטיזציה של המערכת ככל האפשר מורידה עומס ממחלקת ה IT. רק שאוטומטיזציה צריכה להתבסס על כל מיני PKI – ים שדורשים מידע ברור על מה שקורה בכל רגע ורגע במערכת, מהי ההתנהגות הנורמאלית של המכונה, מה זה התנהגות חריגה, מתי יש עומס מתי אין. יש גם חישוב קוי מגמה, מציאת סדרות התנהגותיות, בקיצור המון BI. ולאחר שיש תובנות צריך גם להציג אותם נכון. התרעות מצד שני יוצרות לפעמים בעיה אם מגזימים איתם ומקבלים את תופעת ה "זאב זאב" שמביאה לזה שמתעלמים דווקא מההתרעה שיכולה היתה להציל את המערכת.

יצאנו להפסקה כשלאחריה עלה לבמה בן חגי ודיבר על Vcloud Director עם ספקי מיחשוב ענן שמספקים עננים למערכות של VmWare עם היכולת לייצר שכבת הפשטה מעל הכלי באמצעות Service Manager תוך הוספת Orcastration לקבלת Governance נדרש תוך שימוש במנוע WorkFlow.

חגי העביר פיקוד ליניב וינברג שדיבר בעיקר על יכולות ה Scripting של המערכת שבאמצעותה ניתן לעשות הכל החל מאוטומציה של תהליכים, שליטה ובקרה, וכמובן Complince. כשיניב שאל כמה עושים Script – ים על הכלי רק 2 מתוך 150 משתתפים הרימו ידיים וזה דבר איום ונורא לדעתי.

מעניין של VmWare יש בתחום הזה בעיה דומה לבעיה שיש למיקרוסופט. לא מספיק אנשי IT משתמשים בשפות ה Script לניהול שוטף.מקורות הבעיה נובעות מזה שכיום, כל איש IT רציני חייב לדעת תכנות. בעוד שבתהליך ההכשרה של אנשי IT בדרך כלל תכנות אינו חלק מתכנית הלימודים, ויש ממנו אפילו רתיעה כי זה שייל ל"מפתחים". משעשעת האבחנה שאין כמעט Admin ב Unix שלא מכיר תכנות ב Shell Script וחלקם הגדול מכיר גם שפות תכנות אחרות כמו Perl. בשעה שמעט מאד (יחסית) אנשי IT בעולם המיקרוסופטי יודעים VbScript ו/או PowerShell. הפתרון ה VmWare – י לבעיה מאד דומה לזה של מיקרוסופט. Script Center עם מאגר Script – ים מוכנים וכלים שמקלים על תהליך הכתיבה.

בשלב הבא עלתה לבמה מורן ממחלקת הפיתוח של VmWare בישראל והציגה את ה Infrastructure Navigator שהוא פיתוח כחול לבן ונמצא בשלב הביתא. הכלי נותן מבט על של מיפוי ותלויות של Services במערכות הוירטואליות על מנת לקחת החלטות נבונות על ההשפעות שיש לפעולה שנעשית על מקונה וירטואלית אחת על מכונות אחרות הקשורות אליה.

לסיןם עלה לבמה עידו גרון מהיטאצי והציג את מורכבות הבעיה של גיבוי מערך של מכונות וירטואליות. תחשבו רק על זה שאתה מגבה ברזל אחד ובעצם בתוכו יש 30 מכונות שונות שכל אחת מהן יכולה להיות DataBase ו/או Exchange שלכל אחת מהן יש דרישות קונסיסטנטיות ושלמות שונות ואם אתה לא מתחשב בכל הפרטים הללו אתה בעצם לא מגבה כלום. או בניסוח יותר מדוייק, אתה חושב שאתה מגבה ובעצם אתה לא. תוסיפו לזה את הבעיה ההפוכה, איך מהגיבוי הבינרי הזה מוציאים למשל DataBase אחד בלבד שאותו אתה רוצה לשחזר ואתה מגיע לבעיה מאד מורכבת. השימוש ב Agents לכל מכונה לצורך הגיבוי זה פרתון שכבר מזמן פשט את הרגל ב Large Scale. תוסיפו לזה שגיבוי צריך להכיל מנגנונים לביצוע Deduplication, להתבצע כך שעומס הגיבוי לא יעצור את הייצור ועוד מליון דברים שהמוצר גיבוי של היטאצי עושה. מי שרוצה לקבל מושג על המורכבות שיתחיל ב VADP (שמחליף את VCB).

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

ההקלטה שלי במפגש פורום NET. של תפוז במכללת סלע עלתה לאויר

2012-02-04T20:45:46Z

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

ארוע Going Native 2012 ברדמונד, ההרצאה של Bjarne Stroustrup

2012-02-04T20:35:09Z

למי שלא יודע, אז בחמישי שישי האחרונים, התרחש ברדמונד ארוע Going Native 2010. אני יודע שרבים מאלה שיקראו את הפוסט הזה, שקועים עמוק בעולם המנוהל, ובטח שואלים את עצמם למה זה בכלל צריך לעניין אותם. אז אני מתנצל שאני צריך לדכא אתכם, אבל ++C חזר לאופנה, ולא סתם ++C, אלא מדובר בגירסא 11 של התקן (או טו טו בביתא והאלפא חולק בבילד האחרון), שלא דומה בכלל למה שאתם זוכרים מבית הספר היסודי. מה שיותר גרוע, ++C חוזר לאופנה כל כך חזק, שהוא מעיף הצידה את העולם המנוהל הפשוט והחביב שכל כך התרגלנו אליו. כדאי לכולנו להתחיל ולחזור למקורות. כי כפי שזה נראה כרגע, כל העולם המנוהל שאנחנו מכירים נמצא על סף תהום. וכששואלים את הדוברים הרשמיים של מיקרוסופט על הנושא הזה, הם מבטיחים חזור והבטח, שאנחנו דווקא הולכים להתקדם בתחום המנוהל בקפיצות גדולות קדימה (וכנראה, גם עמוק עמוק למטה, שאנחנו צועקים בדרך תהווווווום!!).

מאיפה נובעת תיאורית הקונספירציה המופרכת והבלתי הגיונית בעליל הזו, אין לי מושג. אבל SilverLight על Windows Phone 8 על ARM, לא רץ תחת NET. אלא כתוב ב Native. ה UI של Windows 8 לא כתוב ב WPF (שרץ על NET.), אלא משתמש במנוע WinRT, שהוא (בטח כבר ניחשתם) כתוב ב Native. בכנס Build האחרון, כמות ההרצאות על NET. היתה זניחה, לעומת כמות ההרצאות על תחום ה Native. תוסיפו לזה כמה התבטאויות אומללות של מנהל בכיר במיקרוסופט (שכבר לא נמצא שם יותר), וקיבלתם בסיס מעולה לתיאורית קונספירציה משובחת, שאפשר לעשות ממנה סרט מתח.

חשוב להדגיש בנקודה הזו, להגנתו האישית של כותב שורות אלה, שכמו כל תיאוריית קונספירציה טובה, אין לה שום קשר עם המציאות והיא מופרכת לחלוטין. למשל, אם כבר מזכירים את הנושא של חלוקת הנושאים של ההרצאות ב Build האחרון, כמות ההרצאות על Java Script היתה יותר גדולה מכמות ההרצאות על #C. מה שאומר שלפי אותו הגיון, העתיד הוא Java Script ותשכחו מ #C, ומה שיותר גרוע תשכחו מ VB.NET. כאן תיאורית הקונספירציה כבר פוגעת במשהו הרבה יותר משמעותי וחשוב מאשר הרס העולם המנוהל. כי למי שלא יודע, Java Script זה לא באמת שפת תכנות. תאור יותר מתאים לייצור הזה, זה גיהנום של תכנות ספגאטי, ולא צוחקים על דבר כזה. כמובן שיש גם לבעיה הזו פתרון פשוט, ניתן לכתוב את דפי ה HTML שלנו עם ++C, וזו סיבה עוד יותר טובה לחזור למקורות. אז לאחר ששוטטנו במחוזות המדע הדמיוני, בואו ונחזור לעולם האמיתי.

מיקרוסופט הזמינה לרדמונד, לכנס שהכותרת שלו היא Going Native, לדבר על גירסא 11 של התקן של ++C את: Bjarne Stroustrup מ AT&T Labs שהמציא את השפה הזו ושהספר שלו על ++C הוא התנך של כל מי שעוסק בתחום. את Hans Boehm מומחה לנושא ניהול הזכרון ואיסוף הזבל ונושא ה Threads. את Andrei Alexandrescu מ FaceBook, מי שכתב את C++ Coding Standards. את Chandler Carruth מ Google המוליך של פרויקט clang. את Andrew Sutton מאוניברסיטת A&M בטקסס. את Stephan T. Lavavej ממיקרוסופט (כינוי חיבה STL תנחשו למה). ואחרון חביב את Herb Sutter שכתב את כל הספרים החשובים על ++C, אבל יותר חשוב מזה, כתב את המאמר הידוע על The free lunch is over בתחום המקבילי. כל האנשים המכובדים האלה (חלקם ממתחרים של מיקרוסופט) הוזמנו להיכל הקדוש ברדמונד, לדבר ולדון במשך יומיים רצופים, לכל מי שהיה מוכן לשלם 120 דולר ולבוא לרדמונד. לכנס הזה נעשה PR בקהילה של ה ++C והוא התמלא לחלוטין במהירות הבזק.

התכנית של הכנס כללה שמונה הרצאות ושני פנלים. לומר את האמת, שקלתי ברצינות לקפוץ לשם, כי כמה הזדמנויות בחיים יש לך להתחכך באצולת ה ++C. אבל מצד שני, טיסה הלוך חזור בשביל יומיים זה לא תענוג גדול. מה ששבר את הקש היה המחויבות שהכל ישודר ב Live. מאחר והפרש השעות הוא מינוס 10, מה שאומר ש 9:30 בבוקר שם זה 19:30 פה זה יצא ממש נוח. בקיצור, התחברתי לשידור החי, כאשר אני מנצל עד הסוף את היכולת של ה Smooth Streaming לעצור ו/או לחזור אחורה, כאשר את זמני ההפסקות ניצלתי כדי לחזור לזמן האמת.

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

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

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

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

אז להלן סיכום פרקטי של הכנס.

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

לאחר מכן עלה לבמה Bjarne Stroustrup ודיבר על הסגנון (החדש) של ++C. זו הרצאה שאני ממליץ לכל מי שמתכנת ולא משנה באיזו שפה, להקשיב לה, כי הנושא של Style והתובנות של Stroustrup בנושא הזה אינן ספציפיות ל ++C.

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

ההגדרה של Stroustrup ל ++C היא A Light-waight abstraction programming language. לטענתו, אין שפת תכנות אחת שמתאימה לכל הדברים לכל שימוש תהיה השפה המתאימה ביותר לו. מצד שני אי אפשר לעשות לכל דבר שפה, כי זה גם המון עבודה וגם פתח להסתבכות ברגע שאתה מנסה לחבר ביניהן ביישום אחד. דרך אגב, Portability יכולה להיות גם בעיה בין דורות שונים של חמרה מאותו יצרן ולא רק בין מערכות הפעלה.

איך להשתמש נכון בשפה, זה אולי החלק החשוב ביותר בשפה ולא ה Syntax. ולזה בדיוק מתכוון Stroustrup כאשר הוא מדבר על Style. תרשמו לכם משפט זהב Bad Code bred more bad code (נכון לכל שפה). יש חשיבות רבה למימשק (נכון לכל שפה). ויש חשיבות ליכולת לתת משמעות למספרים (יחידות עם Type).

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

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

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

בערך בנקודת החצי של ההרצאה עובר Stroustrup לשחיטה מאסיבית של פרות קדושות. הוא מתחיל בזה שהוא מעלה את השאלה מה יותר מהיר לשימוש ב Insert ו Delete, וקטור (המון Copy הלוך וחזור) או רשימה מקושרת (שבעצם לפי הספר נולדה למטרה הזו). מסתבר שהוקטור מנצח בגדול. בהמשך הוא עובר למבני נתונים, ומראה שקומפקטיות מנצחת תכנון OO אלגנטי. אחר כך הוא מסביר מדוע ההנחה ש Low Level Code שווה ביצועים היא שטות מוחלטת. ולסיום הוא מסביר למי שחושב שהתכונה הכי חשובה של ++C היא ירושה, שלא נכון לעשות ירושה בכוח, ושלא כל דבר ב ++C חיב לכלול הורשה, נהפוך הוא, רוב הדברים אינם דורשים הורשה. הדיון שלו בנושאים הללו ובאלה שבאים בהמשך, הוא קטע וידאו שחובה לכלול אותו בכל קורס תכנות (ושוב, התובנות נכונות לרוב השפות והמערכות ולא רק ל ++C).

נקודה שרציתי להדגיש היא הדיון על "אל תמציא את הגלגל". דהינו, אם יש לזה פונקצית ספריה או אלמנט בשפה, אל תכתוב את זה מחדש בעצמך. את הספריה והקומפילר כתבו ובדקו ועשו אופטימיזציה הרבה יותר אנשים ממך (או במקרה היותר גרוע, מהצוות שלך). אני הייתי רוצה לקחת את זה צעד אחד הלאה. לטעמי, שווה לעבור על קוד ישן, ולהמיר קטעי קוד ארוכים, שעושים דברים שכיום נמצאים בשפה או בספריה, לקוד קצר יותר, שמשתמש בפונקציות ספריה סטנדרטיות או בתכונות חדשות של השפה. ולו רק בכדי להקטין את כמות ה Bug – ים שיש לך במערכת. ל C++11 יש סמנטיקה של Move במקום Copy. שוה רק בשביל זה לשנות את הקוד הקיים שלך, כי החסכון בביצועים ובהורדת רמת הסיכוי ל Bug במערכת הוא עצום.

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

ערב עם פורום תפוז במכללת סלע

2012-01-25T08:31:31Z

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

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

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

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

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

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

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

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

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

שורש הבעיה Bug in Reflector ואיך זה קשור להיסטוריה של המחשבים II

2012-01-14T19:33:20Z

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

אל תתעצל, לך לפוסט הקודם.

נו…..

טוב, שלא תגיד שלא הזהרתי אותך.

----------------------------------------------------------

אז להלן רמז נוסף לשאלה למה ה Reflector פישל.

לך בבקשה ל Explorer ופתח אותו באיזה תיקיה שאתה רוצה, לאחר מכן לחץ על עכבר ימין ובקש New Folder. תן בבקשה לפולדר הזה את השם aux, האם הצלחת ? לא, לא הצלחת.

נסה prn ? יש כאן איזה שהוא Pattern ? מצלצל פעמון באיזה שהוא מקום ?

נסה lpt1, מעניין ? מה עם Com1 ? אני מניח שכבר תפסתם את הפרנציף.

אי אפשר לייצר קובץ או תיקיה שהשם שלהן הוא אחד מהשמות שמופיעים ב Global Namespace כשם של Dos Device. למה ? ככה !. מאחר והרפלקטור פותח תיקיה לכל חלק ב NameSpace, אז אם כללת ב Namespace חלק ששמו כאחד מהשמות השמורים ב NameSpace (למשל aux בדוגמא שנתתי), אי אפשר לייצר את התיקיה הזו. מה שאומר שלא תצליח לעשות Export ל NameSpace הזה מה Reflector.

מה שמוליך לשתי שאלות שלא קשורות אחת לשניה. שאלה ראשונה היא למה לעזזל מיקרוסופט עושה את זה ? והשאלה היותר מעניינת, היא למה החברים ב Red-Gate לא בודקים את ה Return code של Create folder ולא מדוחים על הבעיה כמו שצריך, אלא פשוט מדווחים שהכל הצליח בשעה שזה לא הצליח. ואני חותם לכם שהם קיבלו Return Code רע על הבעיה הזו. כי לאחר שהבנתי מה הבעיה, סתם מתוך סקרנות, הרצתי Process Monitor על ה Reflector בזמן הביצוע של ה Export, והוא דיווח לי שהיישום קיבל Failour בנקודה הזו. ואם הוא דיווח את זה לי, הוא דיווח את זה גם להם.

למי שסקרן לדעת מה עשיתי כדי לפתור את הבעיה, אז אני מתבייש להודות שהשתמשתי ב Brute force. שעשיתי Roun trip ל DLL תוך שימוש ב ILDasm ו ILAsm, כאשר בדרך עשיתי Edit ידני על הקבצים, ושיניתי כל הופעה של aux ל aux1 (עשיתי את זה עם Replace all אחד). כן זה לא אלגנטי במיוחד, ואפילו מגעיל, אבל מדובר היה רק ב DLL אחד, ולא היה לי כוח להתקשקש עם זה באלגנטיות.

אני די בטוח שכשהתחלתי את הסיפור הבלשי, לא ציפיתם שהוא יסתיים בשרידים הארכיאולוגיים של עולם ה DOS. אבל אין מה לעשות, Real Programmers use DOS, ושלא יספרו לכם ש DOS מת, הוא איתנו לנצח.

שורש הבעיה Bug in Reflector ואיך זה קשור להיסטוריה של המחשבים I

2012-01-14T17:23:48Z

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

הטעות הכי גדולה שיכולה לעשות מערכת פיתוח/ייצור, היא לעצור במציאת ה Bug, לתקן אותו, ולסמן V. הדבר הנכון הוא לא לעצור ב Bug, אלא לנתח לעומק, את כל השרשרת של הטעויות, שהביאו לכך שה Bug נמצא במוצר הסופי, ולהגיע לשורש הבעיה (The Root Cause of failour). התוצר של התהליך הזה, הוא שלא "רק" פותרים את ה Bug, אלא מגלים בדרך הרבה אחים ואחיות חורגים של אותו Bug, וכתוצאה מזה מקבלים שתי ציפורים ביריה אחת. גם מתקנים את כל משפחת ה Bug - ים, וגם מונעים את החזרה של כל ה Bug – ים מאותה משפחה למוצר.

הבעיה שאני מספר עליה כאן, התחילה משאלה נורא פשוטה, שנתקלתי בה אצל לקוח. איך אני משווה שני DLL – ים כתובים ב NET. ומוודא שהם זהים. השאלה הראשונה שהתעוררה אצלי בנקודה הזו, היא למה לעזזל שמישהו יצטרך לעשות דבר כזה ? שיוציא מה Source Control את הגירסה הישנה, וישווה אותה אל מול החדשה, ויגמור עניין. לאחר חקירה בכיוון הזה, שבה נתקבלו כמה תשובות נבוכות, נסתברו העובדות הבאות: א. יש Source Control, ב. קוראים לו Source Safe, ג. לא היה ניתן להוציא ממנו את הגירסה הקודמת, כי לא שמרו אליו גירסאות תוך שימוש נכון ב Labels (או כל אמצעי סימון אחר). ד. ה Source safe שימש יותר כמערכת Backup ופחות כ Source control. כל זה הוליך לבעיה, שלאחר שה Source שוחזר ידנית, למצב שבו חשבו, שמצב הקוד הוא בדיוק כמו הגירסה שנמסרה ללקוח. נוצר הצורך החשוב, לבדוק שההנחה הזו באמת נכונה. לכן היה צורך להשוות בין ה DLL – ים שמוציא הקומפילר, לאלה שנמצאים בפועל אצל הלקוח בסביבת הייצור.

אז ככה.

שימוש ב Source safe כיום הוא אנכרוניסטי, למה להשתמש במערכת כל כך ישנה ומוגבלת כאשר יש TFS. ולא שהיתה כאן בעיה של רשיון או כסף. ללקוח היה כבר MSDN, כך שהמעבר מ Source Safe ל TFS לא היה יותר מאשר החלטה טכנית מנהלתית, וכמה דקות של Convert. ולהזכירכם, ל TFS יש Brance ו Shelf וקישור אוטומטי ל Work Item בזמן ה Check In, שאלה כלי עבודה שימושיים מאד, שאין ל Source safe.

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

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

אבל זה לא נעצר כאן. השאלה היותר מעניינת היא למה לא ניתן היה להוציא ב Soure Safe את הגירסא הנכונה ? כאן אנחנו נכנסים לתחום ה Process Plumber שלי דהינו בעיה בתהליך. כמה ש Source Safe נחשב לתוכנה דפוקה בימינו, הוא עדיין מערכת, שאם משתמשים בה נכון, יודעת לעשות את העבודה. הבעיה נוצרה מזה שפשוט לא השתמשו נכון במוצר. וכאן מקור הבעיה הוא פער ידע. הצוותים, ומה שיותר חשוב ראשי הצוותים, פשוט לא ידעו איך עובדים עם Labels, ומתי פותחים פרויקט חדש בעץ (שזה שווה הערך המאד לא טוב ולא דומה ל Brance), אלא השתמשו ב Source Safe כמעין מערכת Backup, מבלי להבין שללא תיוג מתאים של פעולות השמירה, המערכת מאבדת את רוב (אם לא את כל) יכולות ניהול הקוד שלה. ומכאן בעצם התחילה הבעיה.

אז ככה.

אם המערכת תעבור ל TFS, מבלי שראשי הצוותים יקבלו הדרכה מלאה על מערכת ה Source Control של ה TFS, הדרכה שכוללת רקע תיאורטי על איך צריך לנהל Source ב TFS ולא רק את התפריטים. המפתחים כבר ימצאו דרך לעשות Abuse גם ל Source control של ה TFS, והבעיה תחזור באיזה שהוא שלב בצורה זו או אחרת. לא משנה לצורך העניין, כמה ה TFS טוב יותר מ Source Safe. כי המערכת הכי חכמה, לא תעמוד בפני המתכנת חסר הידע. השאלות התיאורטיות של מתי נכון לפתוח Brance, איך נכון לארגן את הפרויקט ב TFS, השימוש הנכון ב Shelf, או לחילופין, מהם שדות החובה שעל מפתח למלא בטופס בזמן ה Check In, הם שאלות שצריכות להיות ברורות, לא רק לראשי הצוותים, אלא גם לכל אחד מהמפתחים שמשתמשים בכלי. אז תוסיפו בבקשה לכמה דקות של ההמרה, גם כמה שעות של הדרכה לכל הצוות. ואני מקווה שברור לכם שאם היתה מתבצעת הדרכה דומה, למפתחים וראשי הצוותים, על ה Source Safe, הבעיה שנתבקשתי לפתור לא היתה נוצרת בכלל וההגעה למצב נתון של הקוד לא היתה דורשת התערבות ידנית.

ובאותה הזדמנות.

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

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

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

התהליך היה להכניס את זוג ה DLL – ים שדורש השוואה ל Reflector (אחד אחד בנפרד). ולשמור את ה Source של ה DLL באמצעות Export Assembly Source Code, ולהשוות בין התוצאות עם Diff.

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

הכל הלך כשורה עד שהגעתי ל DLL אחד שסירב בכל תוקף לבצע Export. לא היתה הודעת שגיאה ! פשוט לא קיבלתי קובץ Source.

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

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

למי שרוצה לעשות בשלב הזה Copy Paste לקוד והזה על מנת לבדוק בעצמו, בבקשה

namespace kuku.aux.kiki
{
    public class aaa
    {
        public int bbb()
        {
            return 2;
        }
    }
}

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

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

מפגש קבוצת המשתמים של Project עם יצחק בן לוי על ההיבט האנושי

2012-01-12T07:58:07Z

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

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

אני ישבתי בסוף והיה לי קשה שלא לצחוק ו/או לבכות, כי כל משפט שני של יצחק, הזכיר לי דוגמא מעשית, מאחד הפרויקטים שנקראתי לטפל בהם. אני מזכיר למי שלא יודע, שכאשר קוראים לי לפרויקט, זה בדרך כלל פרויקט תכנה שמתעופף, מסיבה זו או אחרת, אצל הלקוח או ברצפת הייצור. מי שקורא לי, לא עושה את זה רק כדי שאפתור את הבעיה הנקודתית, אלא גם כדי שאאתר את ה Root Cause of Failour, שזה משהו הרבה יותר עמוק מאשר ה Bug הספציפי והנקודתי שהעיף את המערכת. וכאשר אתה מחפש את ה Root Cause of failour, אתה כמעט תמיד מגיע לשלב ה Design של הפרויקט, ולכל ה Process שלו. ומכאן ההזדהות העמוקה שלי, עם המון מהתובנות שהציג יצחק.

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

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

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

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

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

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

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

הנקודה הבאה שרציתי להתיחס אליה היא מה שנקרא Unknown – Unknown. הנושא שצריך להדיר שינה מעיניו של מנהל פרויקט טוב, הוא השאלה" מה אני לא יודע שאני לא יודע". זה נשמע משחק מילים, אבל זה אולי הגורם הכי קריטי למניעת הפתעות יקרות בפרויקט. את מה שאתה יודע שאתה לא יודע, אתה יכול לרשום ברשימת ה Todo של הפרויקט, לבצע עליו ניתוח, ולהפוך אותו ל Action Items ו/או ל Risk Statements עם Mitigation ועם Contingency מוכנים. אבל מה שאתה לא יודע שאתה לא יודע, ממתין באפלה, לרגע הכי לא מתאים, ואז מכניס לך את זה בסיבוב. הטכניקה שהציג יצחק, מציפה למעלה המון Unknown – Unknown, והיא גם מאפשרת לקיים דיון מעשי, על תהליכים של קיצור לוחות זמנים ודרכים אחרות לחסכון כספי בפרויקט.

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

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

ארוחת ערב עם הצוות של Code Value ו Juval Lowy.

2012-01-11T05:41:13Z

היום שלפני סדנת ה Zen Of Architecture עם Juval Lowy היה יום עבודה מלא, Juval ואני הסתובבנו בין לקוחות, שהזמינו את Juval למפגשי יעוץ נקודתיים.

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

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

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

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

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

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

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

חוויות מכנס ביצועים 2011 התשע"ב אי שם

2011-12-29T07:44:00Z

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

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

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

בשלב הבא עלה על הבמה יאיר הורוויץ מ HP והציג את ה Performance Center 11 של HP. ה Performance Center זה גירסת ה Enterprise של Load Runner. אחת התוספות החזקות של הגירסה החדשה היא הקישור ל ALM, מה שמשלב את המערכת בצורה מלאה בכל תהליך הפיתוח. דבר חשוב נוסף הוא מעבר מהסתכלות פרטנית, להסתכלות מערכתית, של בעיות הביצועים. שילוב דרישות הביצועים ברמת הארגון ולא ברמת הפרויקט. בנוסף כל הצעצועים הצפויים, כמו תיזמון בדיקות בשעות שאין משתמשים, חלוקת משאבי בדיקות בין הבדיקות השונות וכו.

לאחר מכן עבר יאיר לדבר על ה Sire Scope, שהוא כלי לאיסוף רציף של מידע וניטור מערכות. החוזקה שלו היא שהוא מכיר את כל המערכות ולא רק את עולם המיקרוסופט, כך שאם יש לך מערכת הטרוגנית, ויש לך כמה ספקים, ומערכות כמו WebSpare של IBM ו מערכות Enterprise של Oracle בארגון. אתה מקבל את היכולת לנטר את כולם בנקודה אחת. וכמובן הוזכרו גם SLA, Tranding, Analysys ו Diagnostics ואפילו BSM.

הפנינה שתרם לי יאיר, היא הסיפור של השימוש בפיצה לבדיקת עומסים. פעם כדי לעשות בדיקות ביצועים, היו מרכזים את כל העובדים עם המחשבים שלהם בחדר אחד. קונים לכולם פיצה, על מנת להבטיח שכולם יגיעו. ואז מבקשים מהם שכולם ביחד, באותו רגע, ילחצו על ה Enter. כדי לייצר עומס על המערכת. ה Load Runner הוא סך הכל שיפור של התהליך, בזה שהחליף את המשתמש הפיזי במשתמש וירטואלי. ובכך חסך את תקציב הפיצה הארגוני. כמובן ש Load Runner נותן היום הרבה יותר ממשתמש וירטואלי, ויאיר לא שכח להזכיר את הפרוטוקולים החדשים שנוספו, כמו למשל תמיכה מלאה ב AJAX, הסתכלות ברמת ה UI באמצעות TruClient ולא רק ברמת ה Web Transport והקורולציות (דורש בשלב זה Fire Fox).

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

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

אז להלן רשימה של כללים (עשרת הדברות) שהוצגו: עובד לאט, לא עובד – ברמת הפרט, לא עובד מהר לא עושים לקוד Check In. לא ניגשים ל DB בלולאה. לפני הפיתוח לתקף הנחות יסוד וארכיטקטורה, ואם צריך תייצר לצורך זה אבטיפוס. תימנע מ Join – ים רבים, גם אם זה אומר שצריך לעשות Denormalization ל DB. כל מה ששואלים עליו בכמויות גדולות, תדאג שיאונדקס. אל תשתמש ב PL/SQL כלוגיקה עיסקית ואל תכתוב שם קוד. אם אתה כותב קוד PL זה כנראה דבר רע. עדיף לשאול שאלה שמביאה Raw Data ואת העיבוד של הלוגיקה העיסקית לעשות בזכרון של המחשב, עם קוד בשפה נורמאלית שניתנת ל Debug ולניהול. עבודה עם ORM ועם אוביקטים, תמיד תהיה יותר קלה לכתיבה מאשר שימוש ב SQL עם שאילתות מורכבות וכתיבת לוגיקה תכנותית בשפה שאינה פרוצדורלית. לעבוד במנות גדולות יותר טוב מעבודה ברמת רשומה בודדת, גם אם הנצילות לא מלאה.

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

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

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

בשלב הזה כולם הלכו לאכול ארוחת צהריים. אני בדרך כלל לא אוכל בצהריים אז התחברתי לרשת ועבדתי קצת.

לאחר ארוחת הצהריים היה פיצול נוסף ואנשי ה Java נפרדו מאנשי ה NET. והלכו לשמוע משי כהן מאורקל ישראל, מה מציעה אורקל בתחום. כאשר באותו זמן, אנשי ה DB, שמעו על ניתוחי ביצועים בזמן אמת, מליאור סבג מאורקל ישראל. לומר את האמת, אם הייתי פנוי, הייתי הולך לשמוע את שי, אבל מה לעשות, וזה היה חריץ הזמן שבו אני הרצתי על הנושא האהוב עלי Production Dbugging.

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

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

הסתבר שהמערכת המדוברת מתבססת המון על Java Script, ואני חייב לומר מראש, ש Java Script זה לא היה אף פעם My Cup of tee. אבל מעניין אותי תמיד לשמוע על תקלות, בעיות, ובעיקר איך עלו עליהם, ואיך פתרו אותם. בהרצאה הוצגו הכלים FireBug ו IEDevTools שהם ספציפיים לדפדפן, ומאפשרים צפיה ב DOM, ביצוע Debug של Java Script, שינוי דינמי של Poperties וכו'. בהרצאה הוצגה דוגמא ספציפית איך שימוש בכלים הללו עזר לפתור בעיה. אחר כך הוצג Fiddler, עם בעיה אחרת ברמת התקשורת בין הדפדפן לשרת, שהוא סיע לפתור. ולסיום הוצג DynaTrace AJAX, עם דוגמאות לבעיות שנפתרו בעזרתו.

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

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

מפגש קבוצת ה Software Craftmenship מספר 9 בבית SAP ברעננה

2011-12-25T17:59:00Z

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

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

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

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

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

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

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

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

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

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

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

זה שהיה למישהו נסיון רע עם ארכיטקטים לא מקצועיים (ושוב אנחנו חוזרים לנושא של מקצוענות), לא משנה את העובדה, שהארכיטקט והארכיטקטורה קריטיים להצלחת הפרויקט. ואני לא מקבל את הטיעון שהארכיטקט מבזבז את זמנם של המפתחים בזמן שהוא עושה את הארכיטקטורה. אני בדעה שלפני שלוקחים שישים מפתחים, ומתחילים לכתוב קוד של מוצר, במוד של Free Running (או Agile או Scrum), רצוי מאד שמישהו יראה את התמונה הכללית, יעבור על ה Use cases, יעשה את ה Decomposition, ויבנה ארכיטקטורה שתעמוד בפני כל שינוי שהמערכת אמורה לעבור בשנים הקרובות. כי אם לא תעשה את זה, תקבל מערכת, שעלויות הייצור והתחזוקה שלה, הן הרבה מעבר למתוכנן ולצפוי. וכן, עדיף שצוות של 60 מתכנתים ישב שלושה חודשים, ולא יעשה כלום בקוד של הפרויקט, אלא יקדיש את הזמן ללימוד של טכנולוגיות, וכלים, ו Coding Standards, בזמן שהארכיטקט יושב ועושה את ה Decomposition. במקום לרוץ לשום כיוון, ולקבל מהר הרבה קוד, שהדבר הנכון היחידי שצריך לעשות איתו, הוא לזרוק אותו לפח.

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

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

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

טוב, הוצאתי מספיק אש וגופרית על הנושא הזה, ובואו נעבור לנושא הבא. הדיון על Scrum וכל שאר נושאי ה Agile למיניהם לא עניין אותי יותר מדי, כל טכניקה שתגרום למפתחים לכתוב קוד מקצועי ונכון טובה בעיני. שכל ישר תמיד חשוב. וכמו שאמר אחד המשתתפים (שהידע שלו ב Scrum רב משלי), ניתן להסביר מה זה Scrum בכמה שעות, ולא צריך הסמכה ו Certification בשביל להיות מומחה ומיישם של עקרונות של "שכל ישר". מה שחשוב זה התוצאה הסופית. קוד שעונה למפרט, ונכתב לפי כללי הארכיטקטורה שקבע הארכיטקט. כשאני למדתי "שכל ישר" בפרויקטים, קראו לזה (בעולם המיקרוסופט) MSF. היום כולם מכירים את זה כשבלונה של פרויקט ב TFS, שאף אחד לא יודע בדיוק איך משתמשים בה. אהבתי את הקטע של ה Least Capable Manager בתור מנהל האיטרציה, יש בזה הרבה חכמת חיים.

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

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

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

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

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

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

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

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

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

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

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

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

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

תזכורת ומידע נוסף על יום עיון The Zen Of Architecture עם Juval Lowy ב 22/12/11

2011-12-05T18:13:02Z

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

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

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

יום עיון The Zen Of Architecture עם Juval Lowy ב 22/12/11

2011-11-26T19:44:52Z

ניצלתי את ההזדמנות ש Juval Lowy מחברת IDesign Inc מבקר באירופה, והצלחתי לגרור אותו לארצנו הקטנה, כדי שיעביר יום עיון, על הנושא החזק שלו, ארכיטקטורה. היום נקרא The Zen of Archirecture ואת כל הפרטים על יום העיון המיוחד הזה תוכלו למצוא בקישור הבא.

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

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

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

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

מפגש קהילת מנהלי פרויקטים עם עופר רשף על שכנוע מחזיקי אומצות

2011-11-12T17:05:00Z

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

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

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

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

מפגש קבוצת משתמשים SBS וה Community RoadShow SMBMVP

2011-11-07T10:30:03Z

הארוע של ה Community RoadShow SMBMVB, שהתרחש ביום חמישי שעבר, לאורך כל היום, באולם דקל, במשרדי מיקרוסופט ברעננה, היה מעניין מהרבה בחינות, ולא רק מהבחינה המקצועית (ששם הוא היה ממש משהו מיוחד). בואו ונתחיל מזה שהיוזמה לארוע לא באה ממיקרוסופט, אלא מקהילת ה MVP של SBS. היוזמה היא של Jeff Middleton שהוא MVP של SBS בניו אורליאנס, וגם המייסד של חברת SBS Migration, שתחום המחיה העיקרי שלה הוא המרות מגירסה לגירסה של SBS (כולל מעברלהתקנות נפרדות, לחברות שגדלו מעבר לתחום הכידאיות של SBS).

למי שלא יודע מה זה SBS אז להלן הסבר קצר. יש למיקרוסופט חבילה שנועדה לעסקים "קטנים" שנקראת SBS, או בתרגום Small Business Server. החבילה הזו בקומבינציות שונות, נועדה לעסקים שיש להם עד 75 עובדים, והוא כוללת בתוכה את כל מה שעסק עד גודל כזה צריך בחבילה אחת. דהינו שרת קבצים, שרת דואר, SharePoint אתר Web, גישה מרחוק וכו'. היתרון של החבילה הזו, מעבר לקומפקטיות שלה (פחות שרתים כי זה All in one כזה) הוא כמובן במחיר. שהוא משמעותית יותר זול, מאשר לרכוש את כל הקומפוננטות והשרתים בנפרד.

ברור שככל שיש לך יותר עובדים, כך האטרקטיביות של החבילה יורדת. וכדי לשים דברים בפרופורציות, חשוב לציין, שלמרות שהמספר המקסימלי של משתמשים בחבילה יכול להגיע ל 75, בפועל, סטטיסטית, בממוצע כלל עולמי, מספר ה Clients לחבילה כזו הוא 11. בארץ, 50 עובדים נחשב לעסק גדול, אבל בלי לפגוע באף אחד, 50 עובדים זה לא Enterprise והמונחים העולמיים לתאר את זה, זה Small. אני לא הולך למכור לכם את SBS, זה הג'וב של מיקרוסופט ולא שלי. אני רק מסביר מה זה SBS. אבל חשוב לציין, שאם אתה עסק של 3-20 עובדים, אתה יכול, בעלות נמוכה מאד, להפוך לעסק עם תשתית המיחשוב המודרנית ביותר שמיקרוסופט יכולה לתת, ואתה לא צריך בשביל זה להוסיף ל Pay Role שלך עשרה אנשי IT.

לצורך המפגש הזה הגיעו מחו"ל Jeff Middleton מניו אורליאנס בארה"ב, Marina Ross מהולנד ו Oliver Sommer מגרמניה, כולם MVP של SBS. מצד הגיע Greg Starks מיוסטון (גם כן בארה"ב). את הזוית הישראלית נתן יזהר הורוביץ שיש לו מקום של כבוד בקהילת ה SBS. את המימון לנסיעה נתנו הספונסרים מיקרוסופט ו HP ואת השיווק לארוע נתנה קהילת קבוצת משתמשי ה SBS של סטיבן וחיים. זה שהמפגש אורגן בעצם על ידי הקהילה (העולמית) ולא על ידי מיקרוסופט, גרם לכך שהמפגש היה ממוקד יותר בנושאים שמעניינים את הקהילה, ופחות בנושאים שיווקיים (פרט אולי להרצאה של נציג HP).

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

לאחר מכן קיבלנו סקירה על הצעצועים של HP, בעיקר מוצר ה Proliant Micro Server שגודלו חצי ממחשב רגיל, בעלות זולה מאד של פחות מ 1,300 ש"ח (אנחנו מדברים על Server ולא על תחנת עבודה) שמסוגל להרים שרת SBS שלם בארגון קטן עד בינוני. ועל עוד מוצרים דומים שנועדו לשוק ה SBS ולשוק ה MultiPoint.

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

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

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

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

מה חדש ב Windows 8 למפתחי Device Drivers ולכל מי שמה שקורה מתחת למכסה המנוע של Windows 8 מענין אותו

2011-10-27T06:30:07Z

תהליך פיתוח ה Device drivers עובר מהפכה עם ההכרזה על חלונות 8. הכלים עברו שידרוגים, יש סביבת פיתוח חדשה Visual Studio 2011, יש פרוטוקולים חדשים לחיבור Kernel Debugger למערכת ההפעלה, יש הנחיות חדשות לגבי תאימות לתכנית ה Logo, יש כלי Debug ו Testing משופרים, ויש כלי אנליזה ואיתור בעיות חדשים ומשופרים, שמאפשרים לאתר בעיות ותקלות בתחום ה Device Drivers מהר יותר.

החלטתי להרים את הכפפה וביחד עם ג'ון ברייס מכללת הי-טק, אני מרים יום הדרכה שלם, שמוקדש לכל מה שחדש ב Windows 8, מנקודת מבט של תשתית ה Drivers של מערכת ההפעלה. אני יודע שכולם (כולל אני) מתלהבים מממשק המשתמש החדש Metro UI. אבל כל התמיכה של מערכת ההפעלה החדשה ב Sensors וב Touch, מבוססים בסופו של דבר על היכולת של מערכת ההפעלה לתמוך בחמרה שמספקת את המידע הזה. ויש המון חידושים מעניינים בתחום הזה ב Windows 8.

מה יהיה לנו ביום העיון ? מה לא !

נדבר על עולם החמרה החדש והשינוי שהוא יוצר בתחום ה Device Drivers. על שינויים אסטרטגיים במדיניות של מיקרוסופט בתחום ה Device drivers ועל השפעת השינוים האלה על מפתחי Device Driversומפתחי יישומים לחפיצים. נדגים ונסביר סביבת הפיתוח החדשה ל Device Drivers, התוספים החדשים, ותמיכה אחורה. תהליך ה Build החדש, כלי הבדיקה החדשים והישנים שעברו שדרוג. כלי ה Debug החדשים/ישנים, יכולות התממשקות חדשות ל Kernel וכמובן ה Setup האוטומטי של הכלים. נדון גם בהרחבת השימוש ב User Mode Deice Divers ומדוע מיקרוסופט דוחפת את התחום הזה. איך הכל משתלב עם VS Test, יכולות שיווק ומכירה של היישומים בחנות המקוונת החדשה ועוד נושאים מעניינים נוספים שקשורים לנשא הזה.

מי שמעוניין בפרטים נוספים מוזמן לפנות לקישור הבא.

GadiM - Gad J. Meirwww.idag.co.il