למי שתוהה למה אני כותב את התכתיב הלועזי של שמות הקוד האלה ונזהר לא להכניס אנגלית בכותרת, אני פשוט לא יודע איך לעשות את זה שזה יראה נכון גם ב RSS וגם על המסך. בתוך המלל אני יכול להשתמש ב DIV עם RTL ואז אין בעיה לערבב מלל לועזי ועברי. אבל לא פיצחתי עדיין את הקוד של איך לעשות את זה בשורת הכותרת.
אמש יצא לי לפגוש את David Platt בניו יורק, וישבנו על ארוחת ערב לדון בבעיות העולם. איך אפשר לדבר עם דיויד מבלי שאיך שהוא CAB או why software sucks יעלו בשיחה.
לגבי התוכנה, היא עדיין מסריחה, החלפנו ביננו כמה דוגמאות חדשות לתכנון מבריק של תקשורת עם המשתמש. זה ממש לא יאומן איך המנטרה של דיוד על "המשתמש זה לא אתה", קופצת לי בראש מחדש, כל פעם שאני נתקל במימשק משתמש שאי אפשר לעבוד איתו.
לגבי CAB, ויסלחו לי כולם על שאני ממשיך לקרוא לו CAB ולא משנה את השם כל כמה חודשים לפי הזימזומילה (Buzzword) העדכני, המצב קצת יותר בעייתי. ל CAB יש כמה וכמה בעיות של דעות קדומות שכדאי לדבר עליהם קצת.
CAB במקור בא לפתור בעיה מאד ספציפית, שלא מעניינת את כלל עולם הפיתוח, אלא תחום מאד ספציפי וממוקד של עבודה מול המשתמש, במרחב תרחישים מסויים. אתה חייב להבין בדיוק איזו בעיה CAB בא לפתור לפני שאתה יכול להחליט אם הוא מתאים או לא מתאים לפרויקט שלך. נתקלתי ביותר ממקרה אחד שאנשים התחילו להשתמש ב CAB לבעיה הלא נכונה ויצאו מתוסכלים מזה שהוא לא סיפק את הסחורה (ומגיע להם).
כדאי לציין ש CAB לא מקל על העניין. מצד אחד יש לו עקומת לימוד גבוהה ומצד שני הוא מאד גמיש וניתן לשינוי. עקומת הלימוד הגבוהה גורמת לכך שההחלטה להשתמש בו נלקחת ללא מידע מספיק ולפעמים מוטעית לחלוטין. הגמישות מצד שני נותנת את האשליה, שגם אם CAB לא הכי מתאים, בקלות רבה ניתן יהיה להשלים את החסר. זו אשליה מסוכנת, כי הבעיה היא, שכמות העבודה הנדרשת להשלמת החסר, היא מעריכית (אקספוננציאלית), למרחק של הבעיה שאותה אתה מנסה לפתור, מהבעיה המקורית שאותה CAB מתוכנן לפתור. כך שאם הכנסת את CAB כפתרון למקום הלא נכון, אתה אוכל אותה חזק.
הבעיה הבאה של CAB היא בעיה של זמן ופוליטיקה. מיקרוסופט הכריזה מוקדם מדי על אקרופוליס, שהיה אמור להיות הדור הבא של CAB. אני לא מכיר מנהל פיתוח שיקח החלטה להתחיל פיתוח, מבוסס על טכנולוגיה, שכולם יודעים שהולכת או טו טו להתחלף. אחר כך אקרופוליס מת (או לא מת, אלא רק נמצא בבהקפאה זמנית כבר המוווווון זמן).
עכשיו יש לנו את Prism, שזה לא זה בדיוק זה, אבל מתקרבים. ובכלל הכל עוד בעבודת הגדרה, ופיתוח, ונזיל. ולמרות שיש שיתוף פעולה הדוק עם הקהילה, התוצאה הסופית היא שאין לנו כרגע ביד משהו שניתן לשכנע איתו מנהל פרויקט לקחת החלטה על אימוץ הטכנולוגיה.
הבעיה היא שכל המסלול מחשבה הזה לא נכון. כי אם CAB המקורי והיישן, כמו שהוא, פותר לך את מרחב הבעיה שלך. אז גם עכשיו, למרות ש CAB היא טכנולוגיה ישנה, עדיין כדאי לך לשקול את השימוש בו. ולהזכירכם, WinForms לא מת, והוא איתנו עוד להרבה זמן. ואם אין לך סיבה מיוחדת לעבור בשנים הקרובות ל WPF, אז כדאי לך לבדוק אם הבעיה הספציפית ש CAB פותר, חופפת היטב את מרחב הבעיה שלך (ואם אתה לא יודע מספיק על CAB, קח מומחה שיודע מה זה CAB שיעזור לך, כדי לא לצאת בסופו של דבר מתוסכל).
אם WinForms עם תיקונים קוסמטטים ל WPF לא בכיוון, אז נקודת ההחלטה הבאה שלך, תהיה ברגע שיהיה ברור לכולם, מה זה בדיוק ה CAB החדש, ולא משנה איך יקראו לו בדיוק.