בוא ונמציא את הגלגל מחדש

אחד מהנושאים שאין מפתח שאינו מתלבט לגביו, היא השאלה "באיזה נקודה בדיוק נמצאת כרגע התכנית שלי באמת כרגע ומה בדיוק היא עושה שם". הפתרון הנפוץ ביותר עד היום לקבלת תשובה לשאלה הזו נקרא  Printf Debugging. ואל תזלזו לרגע בטכניקה הזו, שורשיה מגיעים לעומקי עולם התכנה, ושרידים לה נמצאים כבר ב "Hello World!\n" המפורסם של קרניגהם וריצ'י. התחליף לטכניקה הזו בעולם של היישומים הגדולים הוא כמובן Logging ואין מי שלא בונה או משלב בתכנה שלו איזה שהוא מנגנון של Logger. יש כאלה שקוראים למנגנון הנל Tracing שיש לו ניחוח יוקרתי יותר של איתור צווארי בקבוק ומדידת ביצועי מערכת וחש כאלה שמשתמשים במונח Instrumentation, שמתקשר ישירות לעולם ה Production, עולם שמוסיף לכל תשתית כזו, אילוצים ודרישות של הפעלה והפסקה דינמית של כלי הניטור ללא צורך באיתחול מחדש של היישום, ועמידה בדרישות מינימליות של תקורה.

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

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

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

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

אחד מהכיוונים החדשים שהתשתית החדשה מאפשרת, זה לכתוב Device driver שרץ כולו ב User mode. עד כמה שהרעיון לכתוב Device driver ב User mode נשמע מופרך (רק תחשבו על זה, Device driver שכתוב ב # C ), זו עדיין צורת פתרון בעיה שלא היתה זמינה בקלות כזו למפתחים עד לרגע זה, ושוה לפחות להכיר אותה. הרעיונות מה בדיוק לעשות איתה, יצוצו מן הסתם ברגע המתאים.

מי שרוצה לשמוע יותר פרטים על נושא ETW ועל כלים נלוים ומי שרוצה להכיר את WDF ו UMDF. או כל מי שסתם מעוניין בעוגות בורקסים ושתיה חינם על חשבון מיקרוסופט. מוזמן להגיע ביום רביעי הקרוב, בשעה 17:00 לבית מיקרוסופט ברחוב הפנינה 2 (קרוב לצומת רעננה) באולם דקל, למפגש החודשי של קבוצת משתמשי * C ויקבל ממני הסבר אישי על הנושא.

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

למה אתה עדיין משתמש בחץ וקשת ? תעבור לבליסטראות.

השבוע אצל אחד מהלקוחות שלי שוב נתקלתי ב Visual Studio 6. ושוב פעם עלה לי הסעיף. מילא, אם הפרויקט היה פרויקט של VB, שאני יכול איך שהוא לקבל את הקושי, של הטמעת נושא ה OO אצל מי שמעולם לא נחשף אליו (נושא לדיון נפרד). אבל הפרויקט הוא פרויקט של ++ C, עם הרבה שורות קוד, והלקוח עדיין משתמש ב VS6.

ישנם כמה סיבות לכך שפרויקטים של ++ C נשארים תקועים ב VS6 וכולם לא נכונות.

1. ישנם כאלה שסבורים שמעבר מ VS6 משמעותו שהקוד שלהם עובר מ UnManaged ל Managed, דהינו הקוד ירוץ תחת דוט נט CLR, וזה כמובן דבר רע, זה ישפיע על הביצועים, זה טכולוגיה חדשה, יהיו בגים חדשים ובקיצור זה המון צרות. למיקרוסופט יש הרבה תרומה לסברה הזו, שכן באותה תקופה שיצא VS דוט נט, הם צרפו את הסיומת דוט נט לכמעט כל דבר שזז, היה SQL דוט נט ו Windows Server דוט נט ו Office דוט נט. אנשי השיווק ראו בזה הזדמנות מיתוג ושפכו באותה הזדמנות את תינוק ה CLR - י יחד עם מי השיווק.

זו כמובן שטות מוחלטת, כשאתה ממיר פרויקט ישן של ++ C מ VS6 ל VS2005 הוא לא ממיר לך אותו לקוד מנוהל אלא לקוד Native בדיוק כמו ב VS6 (רק לקוד יותר טוב אבל על זה בהמשך).

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

2. הטיעון הבא שאני שומע הוא ש"ניסינו לעבור וקיבלנו כל כך הרבה Errors כך שירדנו מזה מייד".

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

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

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

אני מעורב בהרבה פרויקטי המרה של קוד ++ C מ VS6 ל VS2005. אני יכול לתת רשימה מפה ועד להודעה חדשה של טעויות שהקומפילר העדכני מגלה והישן לא.

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

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

3. הטיעון הבא שאני שומע הוא ש"ניסינו לעבור וקיבלנו כל כך הרבה Warnings כך שירדנו מזה מייד".

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

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

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

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

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

4. זה כלי חדש, נחכה שיגלו את כל ה Bug - ים שלו ואז נעבור.

לתשומת לב VS2005 יצא ב 2005 אנחנו ב 2007.

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

אז להלן כמה סיבות נוספת:

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

במאי 2005 ביקרו בארץ חלק מקבוצת הפיתוח של ++ C במיקרוסופט והעבירו יום שלם על ++ C תחת הכותרת "Visual C++ Accelerator Tour". פעם היתה גישה נוחה לכל הדברים הללו תחת "ארועים קודמים" באתר מיקרוסופט ישראל, אבל לאחר שהם התקדמו למימשק העולמי, אני יכול למצוא יותר בקלות לאיזה Webcast נרשמתי בשנת 2004 מאשר איפה לעזזל המצגות וההקלטות של ארועים שהיו בארץ. בכל אופן, מצאתי את האתר של הארוע ומצורף קישור למי שרוצה חומר נוסף על "למה ++ C של 2005 טוב יותר מזה של VS6".

http://msdn2.microsoft.com/en-us/visualc/aa336400.aspx

ולהלן ציטטה מהמקורות:

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

איך לא לחלק דיסק קשיח ויונית שימושית

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

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

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

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

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

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

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

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

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

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

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

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

ולמה זמן הגישה הממוצע כל כך חשוב ? בגלל קיר הזכרון.

להלן תרגיל ביונית שימושית.

• מהי מהירות מחזור הפקודה ביע"מ (יחידת עיבוד מרכזית) מקובל כיום ? שלושה ג'יגה שזה פחות או יותר שליש ננו שניה.
• מה מהירות הגישה מהיע"מ לזכרון המקובלת כיום ? 833 מגה הרץ שזה בערך 1.2 ננו שניה.
• להזכירכם מהירות הגישה לדיסק היא בערך 10 מילי שניה.

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

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

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

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

מסקנות והמלצות:

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

הדעה שלי על חלוקה למחיצות:

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

קורס לחץ, מבוא לארכיטקטורה עם רון ג'יקובס

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

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

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

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

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