הנושאים החמים
באגים וטעויות שגורמות לתוכנה שלנו לעבוד כמו שצריך הם דבר שבשגרה. למעשה אין כזה דבר תוכנה בלי באגים. בדרך כלל, כאשר מתגלה באג, מאתרים את הסיבה, וקובעים תהליך שבסופו של דבר יפתור אותו ויביא לתיקונו , והתוכנה או המוצר יעבוד כמצופה. אך ישנם באגים שלמרות שהם ידועים, ולמרות שהם ממש ותיקים, הם פשוט לא עולים על שולחן העבודה להפתר, ובדרך כלל מסיבה טובה.
באג ידוע של מיקרוסופט (רמז, חברה ידועה באובססיביות שלה לתאימות לאחור - כלומר שתוכנה חדשה תוכל לעבוד עם חומרה ישנה או רכיבי תוכנה אחרים ישנים), כידוע בלוח השנה הגאורגיאני, כל 4 שנים מוסיפים יום לחודש פברואר למנינם כדי לשמור על התאמה בין השנה האסטרונומית המציאותית לבין לוח השנה ותאריכיו. על פי חוקי הלוח, כל שנה המקיימת את אחד מהתנאים האלו נוסף לה יום אחד והוא ה29 לפברואר: השנה מתחלקת ב-4 אך אינה מתחלקת ב-100 או שהשנה מתחלקת ב100 אבל אינה מתחלקת ב-400.
לדוגמא ,בשנת 2004 היה 29 בפברואר מפני ש-2004 מתחלק ב-4 , בשנת 2000 היה 29 בפברואר אף על פי ש-2000 מתחלק ב-100, מפני שהוא מתחלק גם ב-400, בשנת 2100 לא יהיה 29 בפברואר מפני ש-2100 מתחלק ב-100, אך לא מתחלק ב-400, וכן על זו הדרך.
לפי החשבון, שנת 1900 למנינם לא אמורה להיות שנה מעוברת. אבל, תוכנת EXCELL, מכירה בשנה זו בתאריך 29 לפברואר.
וזה כמובן באג. אמנם מפתיע, אולי מאוד נדיר שיהיה כזה דבר מכיון שמדובר פה בסה"כ בחישוב פשוט של משהו שהוא פחות או יותר סטנדרט בקבלה לעבודה בתכנות (FEEZE BUZZ), אבל בהחלט באג. מיקרוסופט יודעים אותו, אבל לא מתקנים אותו, מטעמי תאימות לאחור. ויותר מזה, יש להם דף רשמי שמסביר היטב למה זה קרה, ולמה הם לא מתקנים את זה. בקצרה, בזמן שיצא אקסל החברה שהיתה מתחרה איתם היתה Lotus 1-2-3 ומכיון ששם היה הבאג הזה, ואם הם היו מתקנים אותו אצלם או יותר נכון לומר מתעלמים ממנו, הדבר היה יוצר חוסר תאימות בנתונים שעברו בין התכונות.
התעלמות מכוונות זו אפשרה להשתמש באותה מערכת תאריכים סדרתית המשמשת את Lotus 1-2-3 ולספק תאימות רבה יותר עם Lotus 1-2-3. התייחסות לשנת 1900 כשנה מעוברת הקלה על המשתמשים להעביר דפי עבודה מתוכנית לתוכנה. למרות שניתן טכנית לתקן התנהגות זו כך שהגרסאות הנוכחיות של אקסל אינן מניחות כי 1900 היא שנה מעוברת, החסרונות שבדרך לעשות זאת עולים על היתרונות. אם היה ניתן לתקן התנהגות זו, היו מתעוררות בעיות רבות, כולל אלה: כמעט כל התאריכים בגליונות העבודה הנוכחיים של אקסל ובמסמכים אחרים יופחתו ביום אחד. תיקון משמרת זה ייקח זמן ומאמצים רבים, במיוחד בנוסחאות המשתמשות בתאריכים. חלק מהפונקציות, כמו פונקצית ה- WEEKDAY, יחזירו ערכים שונים; זה עשוי לגרום לנוסחאות בגליונות העבודה לעבוד בצורה לא נכונה.
בכל מקרה, בגוגל חשבו אחרת, ופשוט לא זרמו עם זה. אין כזה תאריך שם.
כל זה היה מטעמי תאימות לאחור וכדי למנוע באלגן בהמון מישורים, חישבו על השעות עבודה שהיו מתבזבזות בלתקן את הבאג הזה בכל המישורים.
ולסיום, "באג" אחר מאותה משפחה (מיקורסופט...) נסו לפתוח תקיה חדשה או קובץ חדש בשם CON לא משנה מה הסיומת. (רמז, CON זה קיצור של קונסול)
באג ידוע של מיקרוסופט (רמז, חברה ידועה באובססיביות שלה לתאימות לאחור - כלומר שתוכנה חדשה תוכל לעבוד עם חומרה ישנה או רכיבי תוכנה אחרים ישנים), כידוע בלוח השנה הגאורגיאני, כל 4 שנים מוסיפים יום לחודש פברואר למנינם כדי לשמור על התאמה בין השנה האסטרונומית המציאותית לבין לוח השנה ותאריכיו. על פי חוקי הלוח, כל שנה המקיימת את אחד מהתנאים האלו נוסף לה יום אחד והוא ה29 לפברואר: השנה מתחלקת ב-4 אך אינה מתחלקת ב-100 או שהשנה מתחלקת ב100 אבל אינה מתחלקת ב-400.
לדוגמא ,בשנת 2004 היה 29 בפברואר מפני ש-2004 מתחלק ב-4 , בשנת 2000 היה 29 בפברואר אף על פי ש-2000 מתחלק ב-100, מפני שהוא מתחלק גם ב-400, בשנת 2100 לא יהיה 29 בפברואר מפני ש-2100 מתחלק ב-100, אך לא מתחלק ב-400, וכן על זו הדרך.
לפי החשבון, שנת 1900 למנינם לא אמורה להיות שנה מעוברת. אבל, תוכנת EXCELL, מכירה בשנה זו בתאריך 29 לפברואר.
וזה כמובן באג. אמנם מפתיע, אולי מאוד נדיר שיהיה כזה דבר מכיון שמדובר פה בסה"כ בחישוב פשוט של משהו שהוא פחות או יותר סטנדרט בקבלה לעבודה בתכנות (FEEZE BUZZ), אבל בהחלט באג. מיקרוסופט יודעים אותו, אבל לא מתקנים אותו, מטעמי תאימות לאחור. ויותר מזה, יש להם דף רשמי שמסביר היטב למה זה קרה, ולמה הם לא מתקנים את זה. בקצרה, בזמן שיצא אקסל החברה שהיתה מתחרה איתם היתה Lotus 1-2-3 ומכיון ששם היה הבאג הזה, ואם הם היו מתקנים אותו אצלם או יותר נכון לומר מתעלמים ממנו, הדבר היה יוצר חוסר תאימות בנתונים שעברו בין התכונות.
התעלמות מכוונות זו אפשרה להשתמש באותה מערכת תאריכים סדרתית המשמשת את Lotus 1-2-3 ולספק תאימות רבה יותר עם Lotus 1-2-3. התייחסות לשנת 1900 כשנה מעוברת הקלה על המשתמשים להעביר דפי עבודה מתוכנית לתוכנה. למרות שניתן טכנית לתקן התנהגות זו כך שהגרסאות הנוכחיות של אקסל אינן מניחות כי 1900 היא שנה מעוברת, החסרונות שבדרך לעשות זאת עולים על היתרונות. אם היה ניתן לתקן התנהגות זו, היו מתעוררות בעיות רבות, כולל אלה: כמעט כל התאריכים בגליונות העבודה הנוכחיים של אקסל ובמסמכים אחרים יופחתו ביום אחד. תיקון משמרת זה ייקח זמן ומאמצים רבים, במיוחד בנוסחאות המשתמשות בתאריכים. חלק מהפונקציות, כמו פונקצית ה- WEEKDAY, יחזירו ערכים שונים; זה עשוי לגרום לנוסחאות בגליונות העבודה לעבוד בצורה לא נכונה.
בכל מקרה, בגוגל חשבו אחרת, ופשוט לא זרמו עם זה. אין כזה תאריך שם.
כל זה היה מטעמי תאימות לאחור וכדי למנוע באלגן בהמון מישורים, חישבו על השעות עבודה שהיו מתבזבזות בלתקן את הבאג הזה בכל המישורים.
ולסיום, "באג" אחר מאותה משפחה (מיקורסופט...) נסו לפתוח תקיה חדשה או קובץ חדש בשם CON לא משנה מה הסיומת. (רמז, CON זה קיצור של קונסול)
