מסביב לאירופה ב 7 ימים

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

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

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

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

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

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

5. והכי חשוב: את השוקולדים למשרד הביאו באמת מהמדינה שאליה נסעתם ולא מהדיוטי פרי בארץ - הרי זו הסיבה האמיתית שבגללה שולחים אתכם לחו"ל :)

אמנם לא נסעתי ברכבות באירופה, אבל אם הייתי נוסע, בטוח שככה זה היה נראה (ונשמע):

פשע מקוון

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

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

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

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

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

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

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

שיר לסיום.

התקנים לחלונות

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

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

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

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

אגב, יש כלי מצויין בוינדואוס, שנקרא Driver Verifier, המספק יכולת לוודא שהדרייברים שכתבתם תקינים מבחינת ניהול זכרון, עמידה בעומס, עמידה במצב בו במערכת יש מעט מאוד משאבים, בדיקות I/O, זיהוי דד-לוקים, באגים הקשורים בשימוש ברמות IRQ לא נכונות ועוד תכונות נוספות שמפורטות כאן.

שיר הסיום המתאים כאן צריך לדבר על Drivers, אז הנה אחד ה Driving songs הכי אהובים עליי:

מוזיקה וסטטיסטיקה

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

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

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

לא ויתרתי ומצאתי פתרון!

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

כעת, כל מה שנותר לעשות הוא לשלוח את קובץ הלוג במייל, נאמר פעם בשבוע, ומהמחשב הביתי לשלוח את הרשימה ל last.fm. נשמע די פשוט, לא?

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

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

בסוף השבוע אני אנקה קצת את הקוד, אקמפל גירסת release ואעלה אותה לפה, במידה ומישהו יתקל אי פעם בבעיות הקשות שתיארתי פה :)

גם את הסורסים שלי, אשמח לשתף במידה ויהיה ביקוש.

לא נדלג גם הפעם על שיר סיום. הפעם, מחווה לקוף-המדיה. זה שיר שחיבבתי מהרגע ששמעתי אותו לראשונה. שיתוף פעולה בין אוזי אוסבורן ללהקת Coal Chamber.

תלויות או לא להיות

הפוסט הבא שלי הוא בהשראת המאמר שקראתי לאחרונה ב CodeGuru שעסק בצימצום תלויות בפרוייקט C++ על ידי שימוש ב"תבנית המפעל" (Factory Pattern).

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

תרשים מחלקות שלקחתי מהאתר OODesign, נראה כך:

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

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

כותב המאמר ב CodeGuru צייר את התרשים הבא כדוגמא לתלויות בלתי רצויות בקוד:

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

אחד הפרוייקטים עליהם אני אחראי כעת נכתב על ידי ארבעה אנשים (כולל אותי) במשך כ 3 שנים. עבודה באוירה לוחצת ונלחצת כמו בהייטק מצריכה מאיתנו לעשות ויתורים שונים על מנת לעמוד בלוח הזמנים הלוחץ. כמה פעמים הזנחתם warning של הקומפיילר שלוקח יותר מ 5 דקות לתקן ואמרתם שאין לכם זמן לזה עכשיו? כמה פעמים עשיתם include להדרים שאין לכם צורך בהם ואחרי זה לא יצא לכם למחוק כי הבדיקה מה צריך ומה לא תיקח לכם זמן שאתם צריכים להשקיע בפתרון באגים? גם הקוד שלנו מכיל חטאים כאלה.

מהפכני ככל שזה ישמע, החלטתי לעשות שינוי.

השינוי לא יהיה רוחבי, כי זה קשה מידי, לוקח יותר מידי זמן ולא ריאלי במציאות היומיומית שלי. השינוי יהיה הדרגתי ויתבצע כך: בכל קובץ שאני נוגע במסגרת תיקון, שינוי או כתיבה פיצ'ר חדש אני אדאג להעלים את ה warnings ואת התלויות הלא רצויות, אבדוק אילו includes אפשר להעביר לקובץ המימוש ולהוציא מתוך ה header על ידי שימוש ב forward declarations ואמחק תלויות לא נחוצות שנשכחו במרוצת הזמן. בתקווה להגיע לקוד שמתקמפל מהר יותר ונקי יותר.

מעניין איך קריאת מאמר ב CodeGuru מניעה מהפיכות :)

נסיים כרגיל בשיר בנושא.

למה שמישהו עדיין ישתמש ב MFC?

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

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

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

לדוגמא, קחו קטע קוד שכל תפקידו הוא להפוך את הפונט של פקד טקסט לפונט מודגש:


// get the font of the static text control
HFONT hFont = (HFONT)::SendMessage( GetDlgItem(hwndDlg, IDC_MESSAGETEXT), WM_GETFONT, 0, 0 );


// get LOGFONT struct from HFONT handle
LOGFONT lf;
::GetObject(hFont, sizeof(lf), &lf);

// make it bold
lf.lfWeight = FW_BOLD;


// recreate the HFONT handle
hFont = CreateFontIndirect(&lf);


// set the font
::SendMessage( GetDlgItem(hwndDlg, IDC_MESSAGETEXT), WM_SETFONT, (WPARAM) hFont, MAKELPARAM(false, 0) );

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

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

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

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

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

פוסט ראשון

זהו הפוסט הראשון של הבלוג שלי.

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

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

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

נסיים בשיר הנושא את השם של הבלוג, או בבלוג הנושא את השם של השיר...

לא משנה...

הנה זה: