14:35

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

עמית, אתה מכורררררררר :).

 13:25

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

 12:25

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

 11:15

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

חוצמזה, יוחאי מסביר כרגע על הRed & Green bits..

 10:44

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

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

 ליאור - אתה ממש מאיים עם המצלמה הענקית הזאת.

 09:40

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

 09:16

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

 08:35:

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

הודעה זו ככל הנראה תשמיד עצמה עד סוף היום...

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

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

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

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

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

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

האמת על SOA

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

כולנו מיישמים SOA כבר 20 שנה

בלי להיות מודעים לזה אפילו, עוד טרם עידן הWSDL והUDDI, ארגונים יישמו SOA. ברגע שנוצרו שירותים ברשת שמהווים קלט לשירותים אחרים שיש להם פלט משל עצמם - נוצר SOA. אז נכון.. זה לא SOA יפה כמו שאנחנו אוהבים לאהוב. זה SOA שמבוסס על Tight Coupling של אפליקציות שיוצרות חיבור TCP ותלויות זו בזו. זה SOA של קבצים בינאריים שנשמרים בתיקיה מסויימת. זה SOA של Adaptors שמתרגמים הודעות מפורמט אחד לפורמט אחר בגלל שעם השנים עברנו מFlat Files לXMLים, ומXMLים לDB וכו'.

אבל השורה התחתונה - לכולנו בארגונים יש מערכות שמדברות בינהן. כולנו מימשנו בלי להרגיש נדבכים כאלו ואחרים של SOA.

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

ובכל זאת.. מה זה SOA?

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

כאן הצגתי את מתודולוגית הLoosly Coupling והDeCoupling. כאן דיברתי על WSDL. כאן הסברתי על מוצרים כמו BizTalk, iBolt, WebSphere. כאן הסברתי להם מה החשיבות בתכנון מוקדם יותר. או בכלל.. איך אפשר לתכנן קודם. כאן הראתי להם דוגמאות מהיום יום איך תכנון נכון של מערכות שכל אחד ואחד מהם הכיר, היה יכול לחסוך שנות פיתוח 15 שנה אח"כ, כשבצעו שדרוג שלהן מVMS לWindows.

צורת ההעברה

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

ולמה אני כותב את הפוסט הזה דווקא 9.5 שעות לפני שנפתח הכנס?

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

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

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

לעניין הMDI - לפני מספר חודשים פרויקט בארגון שלח לי קריאה דומה; רצו לאפשר לאחד הChilds להיות מעל כל האחרים. הפתרון (המהיר ביותר.. הן במימוש והן במציאתו), כמו שמיקי הזכיר - הגדרת הHost של הChild בתוך הParent נעשית ע"י SetParent.

אלא שכאן ישנן כמה נקודות שחשוב לדעת:

1. האירוח הזה הוא לא MDI. המשמעות היא שעזרים שונים (כמו DevExpress xtraTabbedMdiManager או כל פקד אחר...) - לא יעבדו. הסיבה היא שהטופס הוא לא MDI. הוא פשוט מתארח בתוך Host שאינו ברירת המחדל. ניתן באותה מידה לייצר כפתור, ולקחת את הbutton1.Handle וכך להציג את הטופס בתוך הכפתור. זה ייתן את אותה תוצאה.
2. שימו לב שכן יש לשייך MdiParent עבור הChild! אחרת, אתם לא תקבלו Events דוגמת MdiChildActivate, הטופס לא ידע שהוא צריך להתנהג כילד של טופס אחר (לדוגמא, תגלו שאתם יכולים להזיז אותו למרות שהוא WindowState.Maximized) ותגלו תופעות מרגיזות אחרות כשתנסו להנות מדברים שטפסי MDI יודעים לתת (כמו Collapsing, Sorting וכו').
3. מ1 נובע בין היתר, שאין קשר בין הSetParent לבין הTopMost שהטופס מממש. הבעיה שמתכתחילה הביאה את מיקי לכתוב את הפוסט, היא שTopMost לא עובד כאשר לטופס מוגדר MdiParent. הTopMost לא יעבוד גם כאן... ואם אתם תרצו להחליף בין טפסים וכו' - צפויה לכם בעיה. (זה פתיר.. אבל.. הפתרון לא לגמרי טריוויאלי).
4. במידה וישנם גם טפסים שלא שויכו כך לטופס הParent, הם יתנהגו וייראו אחרת מאלו שכן הוגדרו כך.
5. הטופס יהיה גם מעל פקדים אחרים בתוך הMDI (לדוגמא - פסי הגלילה שנוצרים כאשר ישנם טפסים חבויים בMDI). בכלל, זה אחד השירותים שהטפסים האלו לא יקבלו בכלל.

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

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

למה? הנה כמה דוגמאות:

• שחר ביצע כבר את השוואת האגו והשוואות אחרות. אין ספק שעדיין גוגל יותר רלוונטי. אני הצטרפתי וגיליתי שחיפוש האגו של שמי בעברית לא מעלה תוצאה בעמוד הראשון והשני כלל. רק בעמוד השלישי הוא נתן לראשונה משהו רלוונטי - מה גם שזה היה המופע המושלם הראשון של המחרוזת שחיפשתי. מצד שני, החיפוש המקביל בגוגל העלה משהו מעניין אחר.. מסתבר שוואלה! כתבו עלינו ואפילו לא שמנו לב!.
• הממשק לא נוח לי. אני לא יודע להגיד למה.. אולי זה כוחו של הרגל, אבל.. נראה כאילו מיקרוסופט התאמצו שהעמוד הראשי לא ייראה כמו העמוד הראשי של גוגל. לדוגמא, דחפו את הלוגו בצד ימין.. מה שיוצר שורה ארוכה והמון חלקים לבנים שמפריעים לעין. נדחפו מלבנים צבועוניים בכל מקום... וכו'.
• הגישה לשירותים לא נוחה.. אומנם לדואר האלקטרוני אפשר לגשת מקישור בעמוד הראשי, אבל כל שאר התכונות חבויות בתוך תפריטים בתוך הכפתור Windowslive.
• למה אפשרות התרגום חבויה בתוך תפריט האפשרויות?!?!?!
• מה זה הכפתור הזה בצד שמאל למעלה בעמודים הפנימיים?
• הHelp נוראי. בניגוד לMSDN שניתן לפתוח סעיף מהעזרה בחלון נפרד, אם תנסו לגשת לקישור שבתפריט - תקבלו שוב את העמוד הראשי. לדוגמא http://help.live.com/help.aspx?mkt=he-IL&project=wl_webmasters#faq0 זה הקישור עבור הסעיף "כיצד אוכל לשלוח את האתר שלי אל Live Search?". מצד שני, לחיצה עליו תחזיר לעמוד הראשי של העזרה.
• אומנם חלק מאוד גדול מהשירותים (והעזרה) תורגמו לעברית, אבל.. חלון כזה עדיין מפריע לי:
• המסך הזה - לא טוב. האפקט ה"פלסטי" (ככה זה נקרא?) של הכותרות גורם לזה שקשה לקרוא את הטקסט. הGradient הכהה עם הטקסט השחור עליו... האמת? המסך הזה קצת מזכיר עיצוב של ילד בן 14 שלומד עכשיו Photoshop.
• למה העמוד הראשון בהוטמייל שלי הוא לא הInbox כברירת מחדל?
• העמוד הזה קצת מפחיד אותי בתור עמוד פתיחה:
    (למען הגילוי הנאות אספר שהפכתי את העיצוב לשחור, אחרי שהכחול רדף אותי בכל שאר חלקי האתר)

לא.. זו לא ביקורת סתמית של סתם "דובי לא לא". הכיוון יפה. הביצוע - צורם בעין ומפריע.. לא חלק לי כמו בגוגל.. ובגלל זה, Live.com הוא עדיין לא אתר הבית שלי לחיפוש וGmail הוא עדיין המנוע שאליו אני עושה forward למייל (למרות שעכשיו כשאני doron כרוכית Live.com, אולי אני בכלל לא צריך דומיין..).

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

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

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

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

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

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

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

אלא שיש הבדל מאוד גדול בין #IF ובין ConditionalAttribute, וחשוב שמי שבאים להשתמש בשני יכירו אותו; ConditionalAttribute לא מעלים את קטע הקוד מתוך הAssembly. הוא מעלים אך ורק את הקריאה לקוד הזה.

בתור דוגמא, נגדיר את המחלקה הבאה:

using System.Windows.Forms;

using System.Diagnostics;

namespace MyClass

{

    public class ConditionalClass

    {

        [Conditional("DEBUG")]

        public static void foo() 

        {

            MessageBox.Show("This is some debugging foo..");

        }

    }

}

ונגדיר את הטופס הבא שישתמש בה:

using System;

using System.Windows.Forms;

namespace ConditionalAttributeDemo

{

    public partial class MyForm : Form

    {

        public MyForm()

        {

            InitializeComponent();

        }

        private void btnClickMe_Click(object sender, EventArgs e)

        {

            // Calling our special logic..

            MyClass.ConditionalClass.foo();

        }

    }

}

ועבור btnClickMe_Click נראה:

אם נקמפל עכשיו כRelease ונעבור על התוצרים, נראה שהMyClass.foo לא השתנה כמעט, למעט תהליך אופטימיזציה שהמהדר העביר, שהוריד את הnop בראשית המטודה:

 ומאידך - הbtnClickMe_Click נראה עכשיו כך:

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

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

using System.Windows.Forms;

using System.Diagnostics;

namespace MyClass

{

    public class ConditionalClass

    {

#if DEBUG

        public static void foo() 

        {

            MessageBox.Show("This is some debugging foo..");

        }

#endif

    }

}

והטופס:

using System;

using System.Windows.Forms;

namespace ConditionalAttributeDemo

{

    public partial class MyForm : Form

    {

        public MyForm()

        {

            InitializeComponent();

        }

        private void btnClickMe_Click(object sender, EventArgs e)

        {

#if DEBUG

            // Calling our special logic..

            MyClass.ConditionalClass.foo();

#endif

        }

    }

}

 ואם נסתכל על הIL (בRelease) נראה שאכן, אין אזכור לפונקציה foo:

ובטופס אנחנו נקבל בדיוק את מה שקיבלנו עם הConditional Attribute.

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