המלחמה על RIA

למדנו מילה חדשה, הא? RIA... פתאום, כולם, כאילו זה היה טרנד ההרזייה החדש או ווב ("בועה") 2.0, מזמרים RIA מבין שפתותיהם.
כן, RIA, או במילים אחרות Rich Internet Applications צמחה להיות הבאז וורד החדשה למרות שהיא כבר מסתובבת פה איזה שנתיים פלוס-מינוס. כל מפתח HTML היום (אפשר לקרא להם ככה? מפתחים?) הוא מפתח RIA. זו המגיפה שבאה עלינו לטובה, ואנחנו מתבשמים בניחוחותיה הירוקים (דולרים, סטלנים, דולרים).
ומיד, כאשר יש טכנולוגיה (או אסופה שלהן, יותר נכון לומר) יש Vendors שמתים לשים עליה את הסטאמפה שלהם. הם המציאו, הם הכי טובים, להם צריך להעלות לעולה ובמקרה של RIA זה לא איחר לבוא.
אז מי בעצם יש לנו בחזית?
אם נקפד ראשן של כל מיני הלצות כמו open laszlo, של-UI שלה יש עוד כברת דרך לא קלה לעבור בכדי להתחרות עם השאר, או השטות של "גם אני! גם אני!" גוגל, אנחנו נגיע לשלוש מרכזיות: Flex של הגברת Adobe, ה- Silverlight של העלמה MS, וכמובן JavaFX של... Sun, כמה מפתיע.
אני חושב שתסכימו איתי, שאדובי קלטה את הקטע די משחר ימיו. עוד כשפלאש היה חוד החנית בתחום, אדובי דחפו ודחפו לעבר אפליקציות ווביות יותר רובסטיות בעלות חווית משתמש עשירה יותר. כל אלו הובילו אל פלקס שלדעתי, וגם לדעת אחרים מותירה את שתי האחרות מאחור. מיקרוסופט נזכרה די מאוחר בכל הוייב ומיהרה להוציא את ה- Flash Killer שלה. זוכרים? אותו מוצר שהודיעו עליו לפני... 4 שנים לערך? ששינה לפחות... 5 שמות על הדרך? זה זה. מוזר דיו, את כל הפרזנטציות למוצר של מיקרוסופט בחרה החברה לערוך ב... כן - פלאש. Silverlight של MS אמורה להיות מאד נוחה לפיתוח בייחוד ע"י מפתחי Net. שסביבת הפיתוח והאינטגרציה עם שאר המוצרים בטכנולוגיה הזו אמורה להיות די שקופה, אמה-מה, כאשר נשאלים מפתחי Net. מדוע הם מפתחים בפלקס הם מודים בפה מלא כי "זה עדיין לא שם". מה גם שלעבוד מול מוצר Silverlight משתמש אמור להוריד סביבת ריצה, שבניגוד ל- Flash Player היא ענקית ולא שכיחה (אנחנו עוד נגע באספקט התפוצה של סביבות הריצה מאוחר יותר)
אצל JavaFX הסיפור מעט שונה. זה נכון שבהיות RIA מה שהיא, רב האפליקציות עובדות על שרתים מבוססי JAVA (כמו Tomcat לצורך העניין). מה גם, שאם נסתכל לרגע על אג'נדת הפיתוח הפלקסית, נראה שהכל מכוון לעבודה מול Java (אם אלו POJO ב- RPC), ובכלל, כל FDS, לימים LCDS, הוא ג'אוואי לחלוטין. האינטגרציה היא כה חזקה בין פלקס ל-Backend ג'אוואי שאפילו עם ההתקנה של פלקס אנחנו מקבלים את jRun בתור Application Server. מכל אלו הרי מתבקש ש- Sun המכובדת, תחל להשקיע מעט בפיתוח UI (מבלי להעליב את ה Swing שלה. טוב, נו, עם להעליב אותו). ואכן - הם עשו זאת. שוב באיחור מה, שכן עושה רושם שעכשיו שפלקס נפתחת כ- OpenSource, פרוטוקול AMF יוצא לחופשי, אין עוד חיוב לעבוד מול שכבות ג'אוואיות. אז מגניב שיש עכשיו כלי פיתוח RIA UI בג'אווה, ואני מניח שהרבה מתכנתי-ג'אוה אפורים יתחילו להזיל ריר, אבל... Sun איחרה במעט את הרכבת. בכל מקרה, אסור לזלזל ב- JavaFX. היא נראית לי כחלופה הראשונה שהייתי לוקח בחשבון לו פלקס לא הייתה בתמונה, וייתכן מאד שבעוד כמה שנים, מערך הכוחות ישתנה, אבל בכדי שהוא ישתנה דבר מאד פשוט אמור לקרות לפני הכל: תפוצת סביבת הריצה.
מישהו פעם ניסה להוריד את ה JRE של ג'אוה? זה תענוג שכמוהו רק טפטוף מים קצוב על מצח במרתף עינויים ישנו. זה לוקח עידן שלם. ותאתחל את המכונה, ורגע... יש לנו עוד איזה רכיב שאתה חייב להתקין ואללא ויוסתור ותעשו לי טובה.
ו-MS? להוריד את ה- Runtime Env שלהם? לא תודה. וסטאטיסטית מי שולט? זה הרי ידוע.
אם עד היום לא ידעתם אז המצב הוא כזה: ל-97% מהמכונות המשתמשים בעולם מותקנת גרסה 9 של נגן פלאש. נקודה. ועם זה קשה מאד להתווכח. כאשר תייצר מוצר שאמור לשרת אירגון ענק, ותגיד ל-IT שלו שאתה עכשיו צריך להתקין בכל מכונות הקצה סביבת ריצה חדשה, סביר להניח שמברגה תרדוף אחריו בדרך החוצה. וזו למעשה הגדולה של אדובי. ע"י כך שהם שמרו על הנגן קטן כל העת הזו (ונכון, ואנחנו שילמנו עם RTL) והפיצו אותו דרך באנרים באתרים ופורטלים ומה לא... הם זכו בשליטה הרחבה הזו שמקנה להם כיום את המקום הראשון כ- Vendor של סביבת פיתוח וטכנולוגית RIA.

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

מדוע מתכנתים הם לא קבלנים?

"כי זה ברור שלא".

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

בואו נתחיל מאיזה "אני מאמין" זריז - אי אפשר "לקבלן" עבודת פיתוח כי התוצאה הישירה של "שיטת" עבודה זו היא מספר נכויות לעתיד, כמו: קוד גרוע, יציבות רעועה של מוצר, תחזוקת קוד שתעלה בהמון שעות אדם וצמצום האפשרות לשימוש נוסף בקוד בצורה פשוטה ושקופה (מה קוראים האנשים reusable code).
ברגע שאתה מוצא עצמך, כמתכנת, מדלג על שלבים חשובים כמו Code Design, Code Review, ומאידך מוצא עצמך באופן די תכוף מבצע Re-Factoring לסוגיו, מתקן ריגרסיות וכיו"ב - דע לך שאתה נמצא בנחלת הקבלנים בין אם אתה אוהב את זה או לאו.
אני לא אומר שצריך לקודד עם ראייה עשור קדימה ולעשות Code Review לכל הגדרת משתנה, אבל אסור בא' הידיעה "לקבלן" פיצ'רים. אם אילו לקוחות שבאים עם הדרישה ל"עכשיו ומיד" אפשר להסביר להם שבכדי שמוצר יהיה יותר גמיש לדרישותהם העתידיות, עדיף לשלם עוד מעט זמן כעת, מאשר לשלם בגדול אח"כ. אם זו ההנהלה הדורשת זה הרבה יותר פשוט (או כך לפחות זה אמור להיות). יש להסביר כי קמצנות בזמן פיתוח היום תחזור כבומרנג מאוחר יותר. אין גם על מה להתווכח - זה בדוק, זה קורה, זו המציאות.
זה גם די נורא לראות קוד שהוא ה"בייבי" שלך מקבל טוויסט לצד המעוות והופך לערימה של כיסאות שבורים, המגדל של המלך צב-צב, שכולנו יודעים מה קרה לו בסוף (ומי שלא, בושה...).
מה שכן, אני יודע שאני מתאר כאן עולם די אוטופי, שהרי תמיד יהיו לקוחות גרידיים ותמיד תהיה הנהלה אטומה. מה עושים אם כן? אין לי ממש תשובה... זהו בהחלט דיון שאפשר לנהל פה. בינתיים כל שנותר לי להמליץ עליו הוא להוריד את כובע המגן הפלסטי שכופים עלינו ולהסביר לדורשים שתכנות זה מעט מעבר ל"צריך את הפיצ'ר הזה עד הזמן ההוא". בין אם הם יבינו או לא, זו כבר שאלה אחרת. מה שכן, תמיד צריך לזכור שלמרות שמתכנתים הם לא קבלנים, הם בהחלט פרוצות שילכו לכל המרבה בכסף :).
את זה תמיד טוב לזכור...

פידבק מכם, אנשים....

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

• Persistent framework caching - היכולת לצמצם נפח אפליקציות בפלקס 3.
  
• Flex Builder productivity enhancements - ריפקטור, פרופיילר וכו
  
• Advanced DataGrid - היכולות החדשות של אחד הקונטרולים היותר נפוצים ב- RIA.
  
• steps toward open source Flex - הכיוון אליו אדובה הולכת, BlazeDS וכו'.
  
• Integration with Creative Suite 3 - אינטגרציה עם פלאש.

נושא AIR בכוונה מושמט, מפני שהרצאה בנושא הספיציפי הזה תינתן ע"י איתן אבגיל.

OT: הפוטנציומטר - אפילוג

מה קורה?
בואו ואנסה לקצר את הסיפור:
יום שישי, סאחבק שם פעמיו אל ירושלים המושלגת קלות בכדי לבצע רכישות לשדרוג ענייניו המוסיקאליים. אין ספק שהשלג עורר את השלפוחית ומצאתי את עצמי תר אחר שירותים, או פינה חשוכה. נזכרתי שבבניין-כלל יש חנות מוסיקה וגם שירותים, אז החלקתי לי לשם. בחנות המוסיקה קניתי פוטנציומטר A500K, שזה לא לגמרי מה שאני צריך, אבל יעשה את העבודה, בעוד שסוג B הוא לינארי, סוג A הוא אלגורת'מי (או כך לפחות אומרים), כלומר היחס בין הסיבוב לערך הוא לא ישר. כמה זה עולה אתם ודאי שואלים - 12ש"ח. נכון, זה לא 80ש"ח. אז קניתי שניים. זה גם לא האיכות הכי טובה, אבל זה יעשה את העבודה. האיכות הכי טובה עולה 35ש"ח (נכון, זה עדיין לא 80ש"ח).
משם אל טמבור עבור נייר שיוף עדין, בכדי לנקות כל מיני הלחמות סוררות. משם לחנות אלקט' שם קניתי את כבלים, צינוריות מתכווצות בחום, בלה בלה... ויאללא הביתה.
כמה שעות אחרי זה, והרבה אדי כספית שנשאפו, הגיטרה שלי הפכה לצ'אק נוריס. הוצאתי את קרביה כמובטח, ניקית, הלחמתי הכל הלך כמתוכנן. עכשיו היא לא מרעישה, הווליום עובד נהדר (גם החלפתי את הפוטנציומטר של הטון) וטוב לי על הלב.
את הסופ"ש העברתי בעיקר בנגינה כי אין כמו לגלות מחדש את הסאונד של הגיטרה שלך - כלומר כמה חרא הוא היה לפני-כן, ואיך ניסית לכפר על זה עם אפקטים, מה שגורם לגיטרה שלך עכשיו להישמע מעט מוזר...
ומוסר ההשכל - אל תפחדו לפתוח קרביים, חנויות מוסיקה בר"ג הן גנבים במסווה, אל תשאפו יותר מדי כספית זה וואחד כאב ראש אח"כ.
עלות כל התיקון - בקושי 50ש"ח (אל תשכחו שקניתי שני פוטנציומטרים).
שמחות על ראשיכם.

פלאשו וקוויקסופט נותנים בפלקס ו- AIR!

הכו בתופים וצאו במחולות, שהרי מפאגשו של פורום הפלאש "פלאשו" בשיתוף עם "קוויקסופט" יוצא לדרך כמו הוריקן אל טקסס.
דבר ראשון, בואו הרשמו אל המפגש בקישורון הבא: אג'נדה ורישום.
עכשיו ,לאחר שנרשמתם אפשר לדבר... בנינו זה כנראה הולך להיות האירוע הפלקסי/פלאשי הכי גדול שקורה על אדמת הקודש. לראשונה אדובה ונציגתה בארץ מעודדים אקטיבית את קהילת המפתחים והמעצבים הגדולה שרוחשת כשפים פה מזה זמן רב.
אני גם שמח להיות חלק מתוכנית הערב, כשאשא דברים על החידושים של פלקס 3, ואעיף מעט דוגמאות באוויר רק בכדי לתת טעימות.
איתן אבגיל, חבר יקר ומפתח מחונן, יתן הרצאה על הגרסה החדשה של AIR ובכלל יהיו שיגועים, צחוקים והרבה אנשים מוזרים.
שאלה חשובה הנשאלת היא - אם המפגש הזה הולך לדבר על פלקס ו-AIR, מה למפתחי פלאש בו?
שאלה יפה...
ובכן, מעבר לעובדה שפלקס היא "פלאש למתכנתים" והכוח המהותי של AIR נובע מאינטגרציה עם פלאש, אני חושב שמפתחי פלאש צריכים לצאת מעט מהנישה הקטנה וחמימה שלהם ולהסתכל מעט החוצה. הכלים הללו, שיודברו באירוע, הם הולכים כנראה להיות חוד החנית בפיתוח RIA, ואני אפילו אחטא ואומר Web Enterprise Applications. זה תמיד טוב לדעת מה עוד נמצא בשוק, אילו עוד כלים יש, מה עוד ניתן להשיג בעזרת SWF.

בכל מקרה, מאד מקווה לראות אתכם שם.

OT: מחווה לפוטנציומטר

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

מפגאשו מקצועי בפברואר

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

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

שובו של הג'דיי.... טוב נו, בקטנה.

אני לא חושב שאפשר ממש לקרא לזה כך, אבל מה? אנחנו נתקטנן? אנחנו? מפתחי פלקס/פלאש או סתם חטטנים בלתי נילאים, אנחנו נתקטנן על כותרת זו או אחרת? לעאא....
ולמה אני חוזר, כמו שד משחת, כמו ספיידרמן חיגר, כמו מומיה מהמתים? ברור - בגלל איוולת. שכן, אין מקום יותר טוב למצא בו עברות קוד יותר מאשר פלקסל'ה, והחברה שלו Cairngorm, ובפרק היום: ViewLocator.
למי שמכיר ועוסק ביצור הכלאיים Cairngorm (אם אתם לא מכירים, תגגלו על זה, זה שם, עצלים) ודאי נתקל במחלקה ViewLocator שלכאורה תפקידה נראה כאפוזיציה ל MVC, שהרי לפי MVC, אסור ש-view אחד יכיר את רעהו, מה שלמעשה מספק. המחלקה אומרת "תן לי את שם ה ViewHelper שאתה מחפש, ואני כבר אביא לך אותו ע"י מנגנון רישום views שאני מנהלת.
זה ממש חארבנה, אתם ודאי מבינים... אבל מי מאיתנו לא חטא, והשתמש במחלקה הזו פה ושם על חשבון code design נכון?
לאט לאט החלו לעלות סברות שאין כבר מקום ל- ViewLocator כאשר באים לעשות design נכון לקוד, ברם המחלקה הזו נשארה עודנה תחת Cairngorm, ואני, חמדתי לדעת, למה בדיוק התכוון המשורר שהותיר אותה שם.
מייל אחד לאיש קשר באדובה והכל התחוור אל מול עיניי:
"אדובה ממליצים לא להשתמש בה", הוא אמר... " למעשה היא תהפוך ל deprecated בגרסאות הבאות".
"Deprecated? זאת אומרת, שמחר הקוד שלי לא יעבוד?"
"כן, בדיוק - הוא לא יעבוד".
מגניב, מרענן, משמח-לב.
שימו לב, פושעי-קוד קטנים. חדלו להשתמש בסקביאס התכנותי הזה, ועברו לפתרונות יותר אמינים (יש כאלו לרב, תגגלו... מה, אני עובד אצלכם?)

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

Practicing Flex Binding

הנה טיוטת מצגת שכתבתי להבהיר את נושא ה-Binding והשימוש בו. מקווה שתמצאו את זה יעיל עבורכם (צר לי על האנגלית, זה נכתב לצרכי עבודה):

What is "Binding"?
Binding is a Flex mechanism that let us "bind" a property of any sort to a destination. The destination can be a control attribute, a setter function on so forth…

How do I implement binding?
There are 3 main methods to create binding relationships:
1. Use the curly braces inline of the control or object we wish to bind to a source.
2. Use the Binding tag which can enable us to bind many sources to one destination.
3. Use the BindingUtils.bindProperty() method which needs to manually be set. It creates a ChangeWatcher instance that can be used later to control the binding. This method is more elegant than using the ChangeWatcher directly, but basically does the same.

What triggers the Binding?
In the case of curly braces, what first triggers the Binding is the life cycle of the document, like so:

createChildren ()
|
createComponentsFromDescriptors ()
|
BindingManager.ExecuteBinding ()
|
Binding.execute ()

This is different when using the BindingUtils.bindProperty(). When using the BindingUtils.bindProperty(), it should be invoked within a method such as the control initialize phase. This method gives us more control on when to switch the Binding on.

What are the drawbacks of binding?
As apparent the benefits of the Binding mechanism are, there are some big drawbacks to this method of developing.
A lot of code is being executed behind the Binding mechanism and part of it is to prevent runtime exceptions from being thrown when not all the binding conditions are met. This fact mean that a lot of "if" and "try… catch" statements are made in the Binding.as and BindingManager.as classes to ensure that all is good for performing a valid binding process, here are some of the cases that fail silently when using Binding:

// Error #1006: Call attempted on an object that is not a function.
// Error #1009: null has no properties.
// Error #1010: undefined has no properties.
// Error #1055: - has no properties.
// Error #1069: Property - not found on - and there is no default value

Only when an error which is not one of the above occurs that an exception is thrown.
The most common error we get is when setting Binding with curly braces. What happens is the control has binding set to it before it was even initialized. The Binding mechanism tries to bind a property to a destination, but the destination is not valid since its owner (the control itself) is not yet fully created. This causes error #1009 - "null has no properties".
When the Binding mechanism reaches this error it stops from performing the binding but does not alert about it. When we have several properties bound like so, you can see how going through this "if" and "try… catch" statements can effect the application's performance.



What is the best practice for working with Binding?
The best practice is to use the BindingUtils.bindProperty() method when dealing with large components that need to render many objects according to the information received. In this manner we can control the instantiation of the ChangeWatcher to prevent as many "silent failures" as we can and later control it better (switching it on and off). This method also provides a better and more elegant access to setter methods using the bindSetter() method.
When dealing with simple controls attributes, such as Label's text and so on, using the curly braces (or Binding tag) should do fine but still we need to keep an eye on what happens behind the scenes.
Another thing to remember is that once a component is bound to properties, as long as it is alive, the binding will keep working within it even if the component is not visible (!). When dealing with components that draw much data this can mean a real performance slowdown to the application. What you need to do is make sure that once the component is not viewable, stop watching after the bound properties that relate to it. This is simply done using the ChangeWatcher.unWatch(). Since BindingUtils.bindProperty() creates an instance of ChangeWatcher this can be easily done. When the component is up and visible again we can reset the ChangeWatcher instance to the source again, and set the current value for the first time, retrieved from ChangeWatcher. getValue() method.

How to debug and monitor the Binding?
1. Debug the Binding.as and BindingManager.as. This is not very trivial to do since those classes are not reachable, so what you need to do is to set a break point on the control you're binding to and using the "drill down" option of the debugger, reach the classes mentioned above. Once there you can set break points to monitor methods entry points and such.
2. Use the BindingManager.debugBinding() method. Don't bother searching, this jewel is not documented and can't be reached. What it does is to output the errors the Binding Mechanism is throwing. You can look at it as a mere flag to whether trace or not. This method works only on binding with curly braces. What you do is call the method where the single argument is a string made of the control name and the destination within it, like so: BindingManager.debugBinding ("myTextControl.text");

Flex 2.0.1 hotfix 2

מה קורה?
אדובי החליטו להוציא את hotfix לגרסאת פלקס 2.0.1, שברגעים אלו ממש אני מתקין אותו, מחזיק אצבעות גם בכפות הרגלים ומנשק שום רק בכדי שתעבוד. את התיקון שבועות הזה לא צריך להתקין מי שכבר רץ אצלו LifeCycle2.5 (זוכרים? FDS החדש...), שזה לכשעצמו מעט אבסורדי מפני שחלק מהתיקונים כלל לא קשורים ל-FDS.
אתם יכולים לקרא על ה- hotfix ב- Tech note הזה וגם להוריד אותו מאותו המקום (158 MB, שזה 6MB יותר מהעדכון של פלקס 2.0 לפלקס 2.0.1, עוד פרט מעניין...). בכל אופן, מה שלכד את תשומת ליבי הוא הדברים הבאים:
1. תיקון זליגת זכרון בקונטרול של ה- Accordion.
2. תיקון זליגת זכרון ב- View Stack (!).
3. אם מסתירים ומראים עמודה אחרונה של DataGrid הסקרול מקבל ג'ננה.
4. Tree אינו מתרנדר נכון לאחר מחיקה של node מסוים.

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

Cairngorm 2.2

רגע! רגע, לכל השדים! אתה לא מספיק לנפוח לצד והנה עוד שדרוג יוצא, עוד גרסה, עוד הנפצה. שנייה!
... ואחרי שהוצאתי מעט קיטור, אני גאה לבשר לכם על dot version החדשה של Cairngorm (אם אין לכם מושג מה זה, או שתדפדפו אחור בבלוג, או שאולי לכו לעשות לכם קפה ושכחו מכל העניין). אז מה היה לנו שם?
תכלס, הסירו תלותיות בין Cairngorm לסוויק (swc) של Flex Data Services, למה? כי זה חוסך בנפח הקובץ הסופי. לא ממש גורם לי לקפץ מאושר, אבל סבבה, למה לא. מה עוד מעניין? שינוי שמות אינטרפייסים כמו IModelLocator במקום ModelLocator (ואוו!) ו... משהו באמת מגניב הוא שהוסיפו מתודה חדשה ל CairngormEvent שנקראת dispatch, והיא (למרבה הפלא) מדספצ'ת את האירוע בלי הצורך לקרא ל- CairngormEventDispatcher. נחמד.
אפשר להעיף commands מה-FrontController בזמן ריצה, אבל אני לא רואה בזה כרגע יעילות משמעותית, ועוד פה ועוד שם עליהם תוכלו לקרא פה.
אז אין ברירה, הא? פשוט לשנס מתניים ולבנות עוד פרוייקט עם הגרסה הזאת ולו רק בכדי לחוש את הטעם הצורב שאקבל עם יציאת 2.3, או רחמנא ליצלן 3.0. מה שעושה לצוות התמיכה שלהם טוב.

ביי בינתיים.

SC3 מוקסי (פן) ואינטגרציה עם פלאש

וואו.
זאת אומרת, לא ממש "וואו", כי אחרי הכל יש הרבה דברים (כן, הרבה) שמרגשים אותי יותר מהידיעה הבאה, אבל ואללא – מגיע להם "וואו", כזה יפה, של ג. יפית לפחות.
בפלאש CS3 יש מצב להוריד mxp (אתם יודעים נו, Flash Extenstions) שנקרא: Flex Component Kit for Flash CS3, שזה למעשה שם מפוצף לסט של קומפוננטות ופקודות שכל תכליתם הוא ליצור קומפוננטות SWC בפלאש שפשוט מתלבשות על פלקס כמו כפפה של בורגנית מהמאה ה-17. הם מגדירים את זה כך: "פלאש הולך להיות האזרח מספר אחד בפלקס", כמה ציורי, הא? מרגש.
בכל אופן, מה זה נותן לנו בתכלס? אז ככה:
ראשית אני אפתח את פלאש אחרי חודשים שלא נגעתי בתוכנה הזו. זה מלבב ובאיזשהו מקום מעט מרתיע, שאחרי הכל, אני לא יודע איך אני אתמודד עם עורך הקוד הביוני שיש שם.
שנית, כל API שנכתב במחלקות אשר מחוברות ל MovieClip אותו רוצים לייצר, יוכר ע"י פלקס ב- code hinting שזה פשוט דבר גדול. מעבר לכך אפשר גם לכתוב Metadata tags עבור אירועים והכל פשוט מתמזג יפה.
פלקס יודע לנהל את ה containers שלו יפה, ואפשר ממש לקבוע בפלאש מה יהיה הגבול של אובייקט מסויים, כך שפלקס ידע להתייחס אליו בהתאם.
מה עוד...? יש לנו את ה- states הפלקסיים שלמעשה מפורשים מ- labels של פריימים בפלאש, שזה מגניב את האשכשכון!
ובכלל, סיפרתי לכם על הגירסה החדשה של פלקס, בשם הקוד מוקסי? ששש...
איפה איפה איפה הקומפוננטות?

עוד באג של כיף

טוב, אני אנסה לקצר (שוב) כי את מכסת העצבים שלי להיום כילה הבאג המטופש הזה. אתם מבינים? רציתי לעשות איזו שורת טקסט יפה שבסופה יש לינק גיבור, אז מיד רתמתי לעזרי את HTMLText וכמה תגיות נאות והופלה – יש לנו את הקישור.
עד כאן טוב ויפה, אבל הקלקות חוזרות ונישנות על הלינק לא הניבו כלום. רוצים לדעת למה? בטח שאתם רוצים לדעת למה, זה מעניין לפחות כמו האניגמה הגדולה בתבל, כמו התשובה למהות החיים עצמם, הפאקינג באגים ההזויים של אדובי – הנה למה:
אם selectable של הטקסט הוא false, אתה יכול ללחוץ עוד ועוד עד שהאצבע שלך תדמם, אבל שום חלון לא יפתח. ומכאן הפתרון האלמותי – selectable=true, או פשוט להשאיר את זה ריק בלי הגדרה.
האם זה אידיאלי? ממש לא. ומה אם אני לא רוצה שיוכלו לבחור את הטקסט, הממ?
שיהיו בריאים.

תיקונים חמים

פאקינג הגיע הזמן. אדובי החליטו לשחרר את סדרת ה hot fixes שלהם עבור פלקס 2.0.1. רובם מתמקדים בקונטרול האהוב עליי DataGrid, שהיה עדיף לבנות אותו ממקלות של ארטיקים מאשר בפלקס. שימו לב לתיקונים 192695, 193106, 192466. אלו פסוקי השטן בכבודם ובעצמם, שאני חתום לפחות על שניים, כמי שהעלה אותם לדיון בתמיכה של אדובי (thnx Nick).
נו שוין, בוא נראה אם זה שווה את המאמץ בכלל: אחח, זה חם.

LifeCycle Data Services 2.5 ?משנה שם, משנה מזל

FDS כבר לא. אתם יודעים, זה משעמם להחזיק את אותה הטכנולוגיה, עם אותו השם. חלאס! כמה אפשר שגרה?! לא רק אני רואה זאת כך אלא גם הארכיטקטים של אדובי, ולכן הם החליטו לשנות את השם של Flex Data Services, לשם המובן מאליו: LifeCycle Data Services 2.5.
יש להם גם תירוץ, שהרי בשל האינטגרציה העתידית עם עוד מוצרי LifeCycle של אדובי (אמממ... אוקיי), חייבים שהמפתחים יבינו שזה חלק מהעניין. אז ראשית, יש פיצ'רים חדשים וכמובן חיזוק של הישנים (אומרים שה- Messaging השתפר בביצועים, נו טוב) בכל מקרה, אני לא אחסוך מכם את העונג הצרוף לקרא בעיון על כל הפיצ'רים ושאר הירקות, תבלו:
LDS2.5

פיצ'ר נחמד שהעלה חיוך על שפתי הוא Server-side PDF generation. זה למעשה יצירת PDF מאפליקציות פלקס. זה נחמד כי כרגע אנחנו נעזרים ב Jasper שלפי מה שאני שומע, זו רעה-חולה ברמות של ימיי-הביניים.

יאללא, כל טוב.

mytoons :OT

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

קצת מוסיקה :OT

כמה דברים עולים לאחרונה. למען האמת, די מרגשים.
הראשון הוא מרטי פרידמן. הגיטריסט הנהדר הזה מגיע לארץ עם ארסנל של מוסיקאים בכדי להעביר פה הופעה או שתיים באיזור אפריל. מיותר לציין את המקום של פרידמן בתור אחד הגיטריסטים הווירטואוזים היותר מעניינים. מעבר לעבודה הנהדרת שהוא עשה ב Megadeth בשנים הטובות שלהן, כל מי ששמע את אלבומי הסולו ודאי התרשם מהסאונד היחודי שלו והגישה היחודית שלו לאירגון ותזמור. אז אפשר לסמוך על זה שסאחבק יהיה שם בהופעה הזו, עם או בלי, העיקר שם.
עוד משהו שעורר את חרון אפי לאחרונה הוא התחרות ההזויה שאדון מר דייב גילמור החליט להשיק בנוגע לחידוש השיר "ארנולד ליין" ע"י להקות שונות. הפרס, כך נאמר, הוא יום הקלטות באייבי רוד, שזה מכובד לכל הדעות, אבל גם לא משהו שיגרום לך לרקוד סלסה כמו אלון אבוטבול. אז מה מקומם אותי?
הרי אתם יודעים שלא צריך הרבה בכדי להביא לי את הסעיף ולשרוף לי את הנתיך כשמדובר באחת הלהקות היותר אהובות עליי. ראשית, מי שם את דייב גילמור להעניק פרס על שיר שהוא בכלל לא כתב? לא שר במקור, ואם להיות כנים – עשה לו בעצם הקאבר בעצמו, שהרי את המוניומנט הפסיכאדלי והפרובוקטיבי הזה כתב לא אחר מאשר סיד בארט המנוח זמבז"ל (זכר מוסיקאי בן-זונה לברכה). אז עם כל הכבוד דייב גילמור יכול להירגע ולחזור לסדר היום. מעניין מה בארט היה אומר.
ומה שעוד יותר מכעיס זו הזכיה של רוקפור. שלא תבינו לא נכון, אני מאד מעריך אותם בתור להקה. שמעתי את גרסת הכיסוי היום בבוקר בתוכנית של רפי רשף (בחלקה אמנם) ואני חייב לומר לכם: זה לא. הם לקחו ועשו מהשיר הזה משהו הזוי עוד יותר ממה שהוא. השירה נשמעת כאילו היא פוסעת שנות אור מההרמוניה המקורית או זו המתנגנת ברקע. לא חבל? חבל.
בכל אופן, זה הסיפור. שיהיה לכם יופי-טופי של שבוע. ואל תשכחו: Right here, right now.

קומפוננטות לעתיד

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

חדשה time entry קומפוננטת

שיטוטים הביאו אותי אל קומפוננטת time entry נחמדת ההופכת את עריכת הזמן למעט יותר אינטואיטיבית ונוחה. פיתוח של ברנדן מוצנר מביא הכלאה בין numeric stepper לשעון. שימושי ביותר. הא לכם.

סופ"ש רגוע.

אל תעצבן את הקומפיילר

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