עבור לתוכן
Magic DevHub

eDeveloperDiv

Members
  • הודעות פעילות

    3
  • הצטרפות

  • ביקר לאחרונה

מוניטין

0 Neutral

אודות eDeveloperDiv

  • דרגה
    Newbie
  1. מגיק 10

    שלום לכולם, ברשותכם ארצה להתייחס למספר עניינים הנדונים כאן. גדי, פתחת בהודעה כה חיובית ומתלהבת ונראה כי התאכזבת מעט מחלק מהשינויים של גרסה 10 ואליהם בין היתר אתייחס עכשיו. בכל מקרה אני משוכנע שככל שתמשיך ותחקור את גרסה 10 תחזור לסכם שהיא אכן מלהיבה ויעילה יותר. גודלי הקבצים אכן בזמן הפיתוח קבצי המקור גדולים פי כמה מגרסאות קודמות שכן המידע נשמר במתכונת XML המאפשרת קריאות של קוד המקור מחוץ לסטודיו. יכולת קריאות זו משרתת אותנו בבחינת שינויים שהתבצעו בקבצי המקור, ובעיקר ביכולת קלה יותר למניפולציה חיצונית לשם שכלול יכולות הסטודיו (ראה יכולת "תשתית הכלים" הקיימת כבר מגרסה 9.4). לעומת זאת גודלו של קובץ הארכיב המשמש להטמעה, כפי שציינת, קטן אף מזה של גרסה 9. נכון שלא ניתן לכווצו עוד יותר, שכן הקובץ כבר מכווץ. בעיתיות הגודל ברוב במקרים, אם לא בכולם, ואם קיימת, היא רלוונטית בעיקר לקובצי ההטמעה אותם יש לשנע למחשבי הלקוח. שאלתי היא, בעידן בו תעבורת מגה בייט נמדדת בשניות בודדות, וקיבולת מחשבים אישיים הולכת וגדלה, האם הגדלים של קובצי ההטמעה (ECF) המתקבלים בגרסה 10, באופן בלתי תלוי לגרסאות קודמות, אכן מהווים בעיה תפעולית או בעיה אחרת? יציאה למערכת הפעלה בגרסה 10, הוxr רישום פעולת ה"יציאה למערכת ההפעלה" מן התפריט. אולם הפעולה עצמה קיימת, וכפי שציינת גדי, ניתן להגדיר עבורה כל צירוף מקשים שנוח לך. רישום הפעולה הורד מן התפריט משתי סיבות עיקריות – התפריט כבר עמוס באפשרויות, ומתכונת יציאה למערכת הפעלה לא ממש שגורה בסביבות פיתוח חלונאיות. הסבת קבצים בודדים כמדומני ערן, שהציג את ההסבה לגרסה 10 בכנס האחרון, התייחס לנקודה זו: יש אפשרות להסב חלקי יישום מגרסה 9 לגרסה 10. זאת ניתן לבצע על ידי הפעלה ידנית של v9converter.exe. בהפעלת הקובץ יש לציין את שם קובץ היצוא של גרסה 9 ואת שם קובץ המטרה שיהווה קובץ ייצוא (לא יישום) של גרסה 10. למשל: v9converter –EXPORT=”V9.exp” –V10EXPORT=”V10.xml”. יש כמובן לעדכן פרמטרים נדרשים כפי שמתואר בפלט העזרה של קובץ ההפעלה. את קובץ התוצאה יש לייבא ליישום בגרסה 10. הסבת קומפוננטות אשף ההסבה המתלווה ל10.1 מאפשר להגדיר באופן מרוכז את קבצי היישום הכללי ואת קבצי הקומפוננטות, כך שתוצאת ההסבה תכלול את הסבת היישום הכללי, הסבת הקומפננטות, ועדכון ההפניות של קובצי הקומפוננטות החדשים. נכון, למרות שפישטנו עוד יותר את תהליך ההסבה הכולל את הטיפול בקומפננטות, עדיין תהליך זה אינו טריוויאלי כמו ההסבה מגרסה לגרסה 9 כפי שצוין על ידי ישי. הסיבה לכך היא מאוד פשוטה – לא היו קומפוננטות בגרסה ותהליך ההסבה לא נדרש להן. לעומת זאת היבטים אחרים בתהליך ההסבה לגרסה 10 פשוטים יותר – למשל בגרסה 10 אין צורך להסב את קובצי הצבעים והגופנים כפי שנדרשנו לכך בהסבה לגרסה 9. הסבה באופן כללי הסיבה למתכונת תהליך ההסבה נובעת ממספר רב של שינויים ארכיטקטוניים המאפשרים את קפיצת המדרגה המשמעותית לגרסה 10. וכמנהגה בקודש, ולהבדיל מפלטפורמות רבות אחרות, מג'יק משקיעה מאמצים רבים לשמר את המערכות ככל שניתן ולאפשר לכל מערכת בקלות יחסית להתקדם ולהתייצב בחזית טכנולוגית חדשה. וכפי שציינתי למרות המורכבות של תהליך ההסבה, שהושקעו מאמצים לא מבוטלים לקיים אותו, נעשו גם מאמצים רבים לפשט אותו, בעיקר על ידי אשף ההסבה המסופק מ 10.1 ושוכלל אף יותר ב SP1. האם יצא לכם להסב את מערכותיכם באמצעותו? "רשומה ראשי" לאן? אין כרגע תוכניות להסיר את "רשומה ראשי". אולם "רשומה ראשי" היא סוגיה בעייתית שכן הוא לא יכול להתקיים בד בבד עם תכונות רבות חדשות אחרות. כך שלעת עתה הוא נדחק מעט לפינה אך ממשיך לתפקד במתכונת זהה לגרסאות קודמות. "לייצר אירועים אוטו'" כפי שכבר הוצע על ידי ישי אינו דבר טריוויאלי כמו שזה נראה. ברגע שבוחנים זאת בקפידה. ותתפלאו, אבל מחלקת מו"פ בחנה אפשרות זו בקפידה רבה וביצעה ריצות יבשות על מספר יישומים אמיתיים, המסקנה היא שבמקרים רבים התוצר המדמה רשומה ראשי הוא לא טריוויאלי ובעייתי לתחזוקה. זה נובע בעיקר מתכונת ה Quick & Dirty של ה"רשומה ראשי" שמאפשר כתיבה מהירה ופשוטה אך בעל השלכות ביצועיות משמעותיות שנראו לעין כאשר מבצעים הסבה אוטומטית לאירועים. מנגנון הסבה של "רשומה ראשי" עדיין נמצא על שולחן העבודה ולא לשם מהלך של ביטול ה"רשומה ראשי" אלא לשם מתן שירות נוסף לקהילה לעדכן ו"לנקות" את המערכות הקיימות. בשלב זה לא ידוע מתי נוכל לספק מנגנון שכזה, שכפי שציינתי קודם זהו מנגנון לא טריוויאלי לחלוטין. אגב, לא שבשם מג'יק אני מתנער ממטלות, אבל קחו בחשבון שמנגנון שכזה שלמעשה עובר על קבצי המקור (במבנה XML נגיש) ומעדכן אותם על פי אלגוריתם נתון יכול להיות מיושם על ידי כל אחד מאיתנו. CTRL+ כפי שהוזכר בכנס האחרון, בכוונתנו לאפשר מנגנון סינון צפייה על גבי עורך המשימה לשם צמצום המידע הנצפה לישויות נדרשות בלבד כדוגמת משתנים מקומיים בלבד, קישורים וכולי. ישי, טענתך בעניין זה אינה לגמרי נכונה. גם ב 10 כמו ב-9 ניתן להגדיר מאפיינים כלליים של טבלה כמו: ביטוי לשם הטבלה, תכונות שיתוף, גישה, מטמון, במקום אחד בלבד. גם אם לטבלה X יש מספר מופעים במספר קישורים שונים. מספיק שנעדכן תכונות אלה בקישור מסוים ועדכון זה יחול על כל יתר הקישורים באופן אוטומטי. שכן הטבלה נפתחת פעם אחת עבור כל הקישורים. מבנה HTML מבדיקה שערכנו נראה כי השימוש במבנה HTML היה דליל ביותר. וכפי שכבר הוזכר, גם כששאלנו בכנס בעזריאלי אודות השימוש, אף אחד לא הודה בשימוש במבנה HTML. בכל מקרה זיהינו כי אחוז השימוש במבנה הוא קטן ביותר בעוד שקיימת אלטרנטיבה משוכללת (אולי לא כה פשוטה) של מיזוג HTML. המשך תמיכה ביכולת כדוגמת מבנה HTML זה לא דבר של מה בכך ויש לכך משמעויות לא מבוטלות. רק על קצה המזלג – יש לתמוך בו במבנים החדשים של קבצי המקור, יש לתמוך בהסבה שלו, ויש כמובן לבצע בדיקות איכות מתאימות. כך שבהינתן שהשימוש בו הוא בהיקף כה נמוך נכנסים שיקולי עלות/תועלת. למרות שלעת עתה גרסה 10 לא מתוכננת להכיל את מבנה HTML וזו העמדה הרשמית של מג'יק, אני אפעל לבחון שוב את העניין. אך בשביל שלא נטפח ציפיות שווא אחזור ואדגיש כי לעת עתה אין כוונה לתמוך במבנה HTML בגרסה 10. קישור בדיקה גם פה נעשו שיקולים של עלות תועלת מול המשך תמיכה ושיקולים של תאימות למתכונת פיתוח עדכנית. קישור הבדיקה מתנגש עם עקרון בסיסי של גרסה 10 וזה הפרדה מוחלטת וברורה של הלוגיקה מהנתונים. כמו כן קישור הבדיקה לא יכול להתקיים (כמו ש"רשומה ראשי") עם סדר מעבר בין שדות השונה מסדר המשתנים. ומכיוון שלהבדיל מ"רשומה ראשי", ניתן להסב ביתר קלות (וגם לא באופן החף מכפילויות) את קישור הבדיקה לפקודת ודא תקינות ברורה וקריאה – זו הדרך שנבחרה. כמו כן עמד לנגד עינינו העיקרון שמרבית המפתחים מוותרים על קישור הבדיקה כי ההודעה שניתנת בעבורו היא מאוד פשטנית ולא ידידותית למשתמש וברוב המקרים הנטייה היא גם ככה לוותר על קישור הבדיקה ולייצר חיווי יותר ידידותי. מה יוצא ללקוח מגרסה 10 הרבה מהיכולות החדשות של גרסה 10 אכן משפרות ומשכללות את עבודת היומיום שלנו בעשרות מונים. יכולות כמו: תת מבנה (SubForm), ניפוי שגיאות, ניהול גרסאות, עורך משימות יעיל ומשוכלל, פונקציות מפתח ועוד רבים וטובים. אך יחד עם זאת קיימות יכולות חדשות המשפרות את התוצר שלנו ללקוח. ביניהם ריבוי משימות – יכולת המקנה למשתמש פרודוקטיביות רבה יותר במסגרתה הוא יכול להריץ דוחות ומשימות אצווה אחרות הלוקחות זמן מבלי לעצור את עבודתו. כמו כן המשתמש יכול לצפות ולהזין נתונים במספר מסכים במקביל ולא נדרש לסגור כל חלון עם המעבר לחלון אחר. לאלה המעוניינים במראה חלונאי עדכני ומשוכלל יותר אזי ההרחבות בעניין זה בגרסה 10 בהחלט רלוונטיות (תמיכה בXP, הזזת עמודות בטבלה, שמירה אוטומטית של שינויי מסך, עריכת כפתורי רדיו חופשית וכולי). חלק מאיתנו נדרשים כבר למערכות מרובות שפות (למשל, עברית/רוסית/אנגלית) כך שעצם התמיכה המלאה ביוניקוד מהווה סיבה מספקת למעבר. וכמובן מחולל הדוחות שחזר אלינו ובגדול. כמו כן, זיכרו שגרסה 10.1 זו רק יריית הפתיחה ואנחנו רק בתחילתה ונכונות לה ולנו עוד יכולות נוספות רבות וטובות – So Stick Around…. אחרית דבר אני בהחלט מסכים עם דבריו של יפתח – עם התקדמותנו (בתוכנה וגם בחיים) מרבית מהדברים אנחנו לוקחים איתנו הלאה וחלק אנחנו מותירים מאחור כדי לפנות מקום ל"חדש". כל יכולת שלכאורה נשארה מאחור, לא נשארה מאחור במקרה. היא נשארה מאחור לאחר בדיקה יסודית. אך יחד עם זאת ייתכן ויש לבחון חלק מהדברים מחדש. אך בסך הכל אני משוכנע שככל שתעמיקו, תלמדו ותנצלו את יכולות גרסה 10 כך תבינו שבשקלול, הדברים גרסה 10 היא אכן אבן דרך עבור כולנו וזו גרסה שתשרת אותנו נאמנה עוד שנים קדימה. בהצלחה, עופר שפיגל מנהל שיווק מוצר
  2. היי שולם, תודה רבה :-) וברוכים הנמצאים. עופר
  3. שלום, קודם כל ברכות על המעבר לגרסה 10. אני משוכנע שככל שתעמיק להכיר את יכולות הגרסה תהנה יותר ויותר מהשימוש בה. אני משוכנע שאם היית מעלה את השאלות והסוגיות הפתוחות שנתקלת בהן בפני מחלקת התמיכה היית זוכה לתשובות מלאות ומקצועיות. אך לפנים משורת הדין ארצה להתייחס למספר נקודות שהעלית פה ובעיקר לנושא טבלאות הזיכרון שנראה כי נותר לעת עתה ללא מענה, אז אתחיל בו. <>טבלאות הזיכרון טבלאות הזיכרון יחד עם משתני התוכנית הראשית והמשתנים הגלובליים (אלה הנקבעים על ידי SetParam) מאוגדים ונשמרים תחת ישות המכונה קונטקסט. עוד בגרסה 9.4, בהרצת יישום לקוח (Foreground) מתקיים קונטקסט אחד ויחיד לאורך כל מהלך הריצה. וזה כולל מעבר בין זמן ריצה לפיתוח (שכן אם תוכנית א' שהרצתי ב F7 הזינה רשומות לטבלה הייתי רוצה להמשיך ולראות נתונים אלה ב F7 על תוכנית ב' – לשם סימולציה ידנית של מהלך אותו יבצע משתמש). כך שטבלאות הזיכרון, כחלק מהקונטקסט נשארו עם תוכנן לאורך כל העבודה בסטודיו. מתכונת זו לא התאימה לסימולציה של יישומי שרת (Background) שאינם מסוג Browser Client – כמו מיזוג HTML, למשל. שכן בריצה במתכונת שרת כל בקשה המגיעה לשרת מקיימת קונטקסט חדש ובתוקף זה מתקיים עותק חדש לטבלאות הזיכרון – זו ההתנהגות לה אתה רגיל וזו אכן ההתנהגות הנכונה ביישומי שרת. לשם קיום שתי המתכונות הללו, כבר בגרסה 9.4 קיימת הגדרת סביבה בשם הקליט "ניהול קונטקסט במחולל אינטראקטיבי". הגדרה זו שהתווספה ב 2SP של 9.4 מטרתה לאפשר לך לקבוע את מתכונת ניהול הקונטקסט. האם באופן של "קונטקסט יחיד משותף" המתאים ליישומי לקוח רגילים, או "כמתכונת ריצת שרת רקע". (אגב בהרצה ראשונה של 2SP ניתנה הודעה המתייחסת להגדרה החדשה שכן ברירת המחדל הייתה "כמתכונת ריצת שרת רקע"). בגרסה 10, הפרדת הרשויות – רשות מחוקקת (Studio) ורשות מבצעת (Runtime) :-) מאפשרת, להבדיל מגרסה 9, להריץ את מנוע הריצה כשרת רקע ובכך לקיים סימולציה אמיתית של זמן ריצה בעודנו מפעילים את התוכניות מהסטודיו. כך שקודם כל ההגדרה של "ניהול קונטקסט במחולל אינטראקטיבי" מגרסה 9.4 כבר אינה רלוונטית. והמתכונת הנכונה לבדוק יישומי רקע היא פשוט להגדיר את "מצב זמן ריצה" ל"רקע" (שורה 9 בלשונית הראשונה במסך ההגדרות). כעת, כשתריץ תוכניות מהסטודיו, כל תוכנית תופעל במתכונת של בקשה המופנית למנוע רקע ותרוץ בקונטקסט נפרד וטבלאות זיכרון נפרדות. יש לזכור כי במתכונת זו לא ניתן להריץ תוכניות מקוונות. אגב, כבר בגרסה 9.4, כמו ב Browser Client אפשר להריץ מספר בקשות נפרדות לשרת רקע שירוצו תחת אותו הקונטקסט וכך לשתף טבלאות זיכרון, משתני תוכנית ראשית ומשתנים גלובליים. לכך יש דוגמה באחד מקובצי הדוגמאות המלווים את גרסת 9.4. <>תעופת הסטודיו יתרון להפרדת הרשויות כפי שתיארתי קודם אכן מגן על סביבת הפיתוח מ"להיזרק" כאשר מנוע הריצה "נזרק" מסיבה זו או אחרת. בלי קשר ליתרון זה של גרסה 10, עדיין יכולות להיות תקלות בסטודיו שכמובן יש לדווח עליהן למחלקת התמיכה וכך נוכל לדאוג לתיקון בעיות אלה. <>גודל הפרויקט אכן גודל קבצי המקור של הפרויקט בגרסה 10 גדולים יותר. זאת בעיקר לשם יצירת קבצי מקור קריאים יותר, כפי שהעדת על כך בעצמך, המאפשרים מניפולציה חיצונית קלה יותר (ראה נושא של תשתית הכלים של eDeveloper). יש לזכור שני דברים בהקשר הזה: 1) להבדל הגדלים האלה אין השפעה על מהירות קריאתם על ידי המנועים. 2) קובץ ההטמעה (ECF) הוא באופן משמעותי הרבה יותר קטן מקבצי המקור בזמן פיתוח. <>קיצורי מקשים לשם תאימות עם סטנדרטים חלונאיים כדוגמת Ctrl+ להעתקה וכולי, ולשם עדכון כללי של הקיצורים, שונו מרבית מהקיצורים המוכרים. למרות שהמוצר מספק קובץ מיפוי מקשים במתכונת הישנה, אנחנו ממליצים להתרגל למתכונת החדשה. <>קבצי צבע וגופן ברצוני לחדד כי לא נדרש להסב את טבלת הצבעים במעבר לגרסה 10. כחלק מהפרדת הרשויות, הופרדו גם קבצי הצבע, הגופן ומיפוי המקשים לסביבת הריצה וסביבת הפיתוח וניתן להשתמש בקבצי הצבע והגופן של גרסה 9.4. <>לסיכום אני מקווה שהצלחתי להבהיר את הסוגיות הפתוחות בהן נתקלת. אני שוב מדגיש וממליץ לפנות למחלקת התמיכה של חברת מג'יק לשם עזרה, יעוץ וליווי ולשם דיווח על בעיות. בחרתי הפעם לענות ישירות לסוגיות אלה שכן נראה כי יש צורך בהבהרה מיידית של הדברים גם לטובת יתר החברים הקשובים לשיח זה. אני מאחל לך ולכולנו המשך הנאה ופרודוקטיביות מעולה עם המעבר לגרסה 10 והשימוש בה. בהצלחה, עופר שפיגל מנהל אסטרטגיית מוצר – eDeveloper.
×