December 2011 - Posts

וידאו הרצאת המליאה של כנס SDP 2011–להבין את חלונות 8 וממשק מטרו–חלק 1

פורסם בתאריך Dec 28 2011, 03:52 PM על ידי eladkatz

בתחילת דצמבר התקיים כנס SDP 11 של סלע בו הרצאתי על חלונות 8 – הבנת ממשק המתשמש והמשמעויות שלו.

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

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

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

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

החלק הראשון:

את החלק השני של ההרצאה אעלה בימים הקרובים.

תגים:TECH, HTML5, win8, VIDEO, sdp11, metro

תכנות לחלונות 8 - יצירת קורא RSS חלק ראשון

פורסם בתאריך Dec 20 2011, 02:54 PM על ידי eladkatz

אפליקציית HTML5 בחלונות 8 היא קודם כל HTML וג’אווה סקריפט רגילים, שלהם אפשר להוסיף אינטראקציה עם WinJS ו WinRT.
כדוגמא, נפתח אפליקציית קורא RSS פשוטה, ולאט לאט נוסיף לה יכולות של הספריות הנ”ל.
פוסט זה הוא חלק מסדרת הפוסטים “תכנות לחלונות 8 בHTML5”.

ניצור אפליקציה חדשה, ונשנה את הHTML ב-default.html כך שיכיל את הקוד הבא:

       <body>

       <div id="container">

        <h1 class="title">

         קורא RSS

        </h1>

        <div id="downloadStatus">

        </div>

        <div id="posts">

        </div>

       </div>

      </body>

הdiv עם ה-id=posts יהיה האלמנט אליו נוסיף את הכותרות של המאמרים בפיד ה-RSS שנירשם אליו.
בנוסף, הdiv שמעליו – id=downloadStatus – יהיה האלמנט בו נרשום את מצב ההורדה. תוך כדי הורדה/הושלם/שגיאה.
ה- HTML סמנטי ופשוט, ונמשיך לקובץ “code-behind” – הג’אווה סקריפט ב default.js:

      (function () {

          'use strict';

          // Uncomment the following line to enable first chance exceptions.

          // Debug.enableFirstChanceException(true);

          WinJS.Application.onmainwindowactivated = function (e) {

              if (e.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.launch) {

               // TODO: startup code here

              }

          }

          WinJS.Application.start();

      })();

בשלב הראשון, כפי שראינו בפוסט “שלום עולם” אין כאן יותר מדי קוד. רק פונקציה אוטומאטית על מנת לסגור את הקוד שלנו, ובנוסף רישום לאירוע onmainwindowactivated של winJS שמקביל לאירוע onload הרגיל של הדפדפן. על מנת שנקבל אירועים מהסוג הזה יש לאתחל את אירועי האפליקציה של winJS כפי שאכן מתבצע בשורה האחרונה.

בתוך האירוע נכתוב את השורות הבאות:

      document.getElementById("downloadStatus").innerText= "downloading posts...";

      WinJS.xhr({ url: "http://blogs.microsoft.co.il/blogs/eladkatz/rss.aspx" }).

             then(processPosts, downloadError);

בשורה הראשונה ניגשים ל-div הרלוונטי ורושמים בו שאנו מורידים את הפוסטים, ובשורה השניה אנו מבצעים קריאה ל xhr שהיא למעשה קריאת Ajax לכתובת בה יש RSS פיד שנוכל להוריד.
חתימת המתודה xhr מחזירה אובייקט שקוראים לו promise – זו הדרך בה בחרו בwinJS לממש תכנות א-סינכרוני. על אובייקט promise מוגדרת המתודה then שמאפשרת לנו לתת שתי מתודות callback. אחת להצלחה, ואחת במידה והפעולה נכשלה.
הקוד יכול להיראות קצת מוזר בהתחלה – אני לא זוכר מתי הייתה הפעם האחרונה שניגשתי לאלמנט ע”י document.getElementById ולא ע”י jQuery, וזה קצת מציק בעין בהתחלה. בפוסט הבא נתקן זאת.

האירוע במלואו יראה כך:

       
          WinJS.Application.onmainwindowactivated = function (e) {

              if (e.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.launch) {

               // TODO: startup code here

               //$('#downloadStatus').text("downloading posts...");

               document.getElementById("downloadStatus").innerText= "downloading posts...";

               WinJS.xhr({ url: "http://blogs.microsoft.co.il/blogs/eladkatz/rss.aspx" }).

                      then(processPosts, downloadError);

              }

לא נותר לנו אלא להגדיר את הפונקציות processPosts ואת downloadError:

      function processPosts(request)

      {

          // clear the progress indicator

          document.getElementById("downloadStatus").innerText = "";

          // parse the RSS

          var items = request.responseXML.selectNodes("//item");

          if (items.length == 0) { downloadStatus.innerText = "error downloading posts"; }

          for (var i = 0, len = items.length; i < len; i++)

          {

              var item = items[i];

              // append data to #posts div

              var parent = document.createElement("div");

              appendDiv(parent, item.selectNodes("title")[0].text, "postTitle");

              appendDiv(parent, item.selectNodes("pubDate")[0].text, "postDate");

              document.getElementById("posts").appendChild(parent);

          }

      }

הפונקציה מקבלת כפרמטר את את התשובה של ה-RSS פיד, ומפרסרת אותו. על מנת לבנות את הHTML היא משתמשת בפונקציית עזר נוספת בשם appendDiv שפשוט יוצרת אלמנטים של HTML בצורה הכי פרימיטיבית:

      function appendDiv(parent, html, className) {

       var div = document.createElement("div");

       div.innerHTML = html;

       div.className = className;

       parent.appendChild(div);

      }

ולבסוף downloadError שפשוט מציגה למשתמש שאירעה תקלה:

       
        function downloadError() {

         downloadStatus.innerText = "download error";

        }

וסיימנו.

נלחץ F5 ונריץ את האפליקציה, ונקבל את המסך הבא:

וקיבלנו את קורא הRSS הפרימיטיבי ביותר בעולם.
בפוסט הבא נוסיף את jQuery ונראה כמה מהקוד שלנו הוא באמת cross-platform, וכמה לא.

תגים:DEV, HTML5, win8, winrt, WinJS, jquery

שימוש ב Unity באפליקציית ווב - איך לרשום רכיבים כסינגלטון בצורה נכונה פר בקשת HTTP

פורסם בתאריך Dec 17 2011, 04:08 PM על ידי eladkatz

Unity הינו רכיב IOC Container מאוד שימושי, ואחד הדברים הראשונים שעושים באפליקציית asp.net mvc זה להשתמש ב-Unity על מנת לבצע רישום ושימוש ברכיבים שונים.

לדוגמא, אם רוצים לרשום DbContext של EntityFramework לשימוש עתידי, אפשר לעשות זאת בשתי דרכים קלאסיות.

רישום רגיל:

       container.RegisterType<DbContext>();

ורישום כסינגלטון:

    container.RegisterType<DbContext>(new ContainerControlledLifetimeManager());

כך ש-Unity מנהל בצורה שונה את ה”חיים” של הרכיב, וכשמבקשים את הרכיב הנ”ל ע”י:

    container.Resolve<DbContext>();

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

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

הדרך הנכונה לפתור את זה היא להגדיר LifetimeManager משלנו שיחזיר את אותו המופע במידה ואנחנו נמצאים באותה בקשת HTTP. לממש LifetimeManager ל-Unity זה די פשוט – כל מה שצריך לעשות זה לממש את המחלקה האבסטרקטית LifetimeManager שנראית כך:

    // Summary:

    //     Base class for Lifetime managers - classes that control how and when instances

    //     are created by the Unity container.

    public abstract class LifetimeManager : ILifetimePolicy, IBuilderPolicy

    {

        protected LifetimeManager();

        // Summary:

        //     Retrieve a value from the backing store associated with this Lifetime policy.

        //

        // Returns:

        //     the object desired, or null if no such object is currently stored.

        public abstract object GetValue();

        //

        // Summary:

        //     Remove the given object from backing store.

        public abstract void RemoveValue();

        //

        // Summary:

        //     Stores the given value into backing store for retrieval later.

        //

        // Parameters:

        //   newValue:

        //     The object being stored.

        public abstract void SetValue(object newValue);

    }

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

    public class PerHttpRequestLifetime : LifetimeManager

    {

        private readonly Guid _key = Guid.NewGuid();

        public override object GetValue()

        {

            return HttpContext.Current.Items[_key];

        }

        public override void SetValue(object newValue)

        {

            HttpContext.Current.Items[_key] = newValue;

        }

        public override void RemoveValue()

        {

            var obj = GetValue();

            HttpContext.Current.Items.Remove(obj);

        }

    }

ואת הרישום ב-Unity לבצע ע”י המחלקה הזו:

    container.RegisterType<DbContext>(new PerHttpRequestLifetime());

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

תגים:IOC, Unity, asp.net mvc

תכנות לחלונות 8 - מבנה WinJS

פורסם בתאריך Dec 17 2011, 02:10 AM על ידי eladkatz

פוסט זה הוא חלק מסדרת הפוסטים “תכנות לחלונות 8 בHTML5”.

מבנה הקבצים של WinJS

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

הקבצים הללו תלויים אחד בשני, והסדר שנוסיף אותם לאפליקציה הוא כדלהלן:

1. base.js
wwaapp.js (after base.js)
ui.js (after base.js)
binding.js (after ui.js)
res.js (after ui.js)
animations.js (after ui.js)
controls.js (after animations.js)
uicollections.js (after animations.js)

על פי הסדר מבסיסי למתקדם (וכנראה הסדר בו נלמד בסדרת הפוסטים הזו)

1. Base.js – מכיל תמיכה בפיצ’רים שכל שאר הספרייה צריכה. בין השאר מכיל יכולות המזכירות את jQuery.

2. Wwaapp.js – תלוי ב base.js, ומספק תמיכה לעבודה עם ה- app-container שמריץ את האפליקציה שלנו. כדוגמא אירועים כגון קבלת פוקוס של האפליקציה, או כניסה למצב השהייה נקבל מכאן.

3. UI.js – תלוי ב base.js. מספק תמיכה ליצירת קונטרולים שמוגדרים ב controls.js, או לקונטרולים של WinJS שניצור בעצמנו.

4. Binding.js – תלוי ב ui.js. מספק תמיכה ב Data Binding, Data Templates וכו’.

5. res.js – תלוי ב ui.js, מספק תמיכה בעבודה עם משאבים כגון תמונות וכו’.

6. animations.js – תלוי ב ui.js, מספק תמיכה באנימציות ומגדיר את האנימציות הסטנדרטיות של חלונות 8 כך שנוכל להשתמש בהן גם אנחנו בקלות.

7. controls.js – תלוי ב animations.js (ולפיכך ב ui.js וב- base.js כמובן) – מכיל את הקוד של כל הקונטרולים של WinJS.

8. uicollections.js – תלוי ב animations.js ומספק תמיכה בקונטרולים של רשימות. הקונטרולים הללו הם המתוחכמים ביותר והמורכבים ביותר ממה שראיתי עד עכשיו.

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

       <script src="/winjs/js/base.js"></script>

      <script src="/winjs/js/wwaapp.js"></script>

      <script src="winjs/js/ui.js" type="text/javascript"></script>

      <script src="winjs/js/binding.js" type="text/javascript"></script>

      <script src="winjs/js/res.js" type="text/javascript"></script>

      <script src="winjs/js/animations.js" type="text/javascript"></script>

      <script src="winjs/js/controls.js" type="text/javascript"></script>

      <script src="winjs/js/uicollections.js" type="text/javascript"></script>

מבנה מרחבי השמות

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

מרחב השמות	תיאור
Control attributes	לא ממש מרחב שמות אבל נחשב חלק מWinJS – מכיל attributes של HTML ש WinJS משתמש בהם.
CSS classes	לא ממש מרחב שמות אבל נחשב חלק מ- WinJS – מכיל את מחלקות הCSS של WinJS
WinJS Namespace	מרחב השמות הבסיסי של WinJS. מכיל תמיכה באג’קס (ע”י אובייקט xhr) ובתכנות אסינכרוני (ע”י promise, ראה פוסט של גיא בורשטיין בנושא)
WinJS.Application Namespace	טיפול בפונקציונאליות שמגיעה מה app-container כגון אירוע קבלת פוקוס, אירוע היכנסות למצב השהייה וכו’
WinJS.Binding Namespace	תמיכה ב Data Binding
WinJS.Class Namespace	פונקצות עזר למימוש Design Pattens של מחלקה
WinJS.Namespace Namespace	פונקציות עזר למימוש Design Patterns של מרחב שמות (namespace)
WinJS.Navigation Namespace	תמיכה בניווט והיסטוריה.
WinJS.Resources Namespace	תמיכה בעבודה עם משאבים כגון תמונות.
WinJS.UI Namespace	תמיכה בקונטרולים.
WinJS.UI.Animation Namespace	תמיכה באנימציות.
WinJS.UI.Fragments Namespace	תמיכה בטעינה של חלקי HTML מקבצים אחרים וניווט אליהם, נקרא Fragments בז’רגון של winJS. חלק מאוד חשוב בהתחשב בכך שלעבור לדף אחר אסור באפליקציות מטרו – אנו כותבים אפליקציות דף אחד (single page applications) כדוגמת פייסבוק או ג’ימייל
WinJS.Utilities Namespace	תמיכה בפונקציונאליות מקבילה לjQuery, כגון בחירת אלמנטים מה-DOM ומניפולציות עליהם (לדוגמא להוסיף ולהוריד css classes מאלמנטים)

תגים:DEV, HTML5, win8, WinJS

תכנות לחלונות 8 - מבוא ל WinJS

פורסם בתאריך Dec 17 2011, 02:05 AM על ידי eladkatz

פוסט זה הוא חלק מסדרת הפוסטים “תכנות לחלונות 8 בHTML5”.

מה זה WinJS ?

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

1. ספריית Utilities (כגון- jQuery) – הספרייה שלמעשה הפכה לכמעט סטנדרט, מאפשרת לבחור אלמנטים ב-DOM ולפעול עליהם, ומספקת לא מעט מתודות עזר כלליות כגון עבודה עם Ajax.
WinJS מספק יכולות מאוד דומות, בכמה הבדלים, שהראשון שבהם הוא ש-jQuery יודע לעבוד עם כל דפדפן, גם עם דפדפנים מאוד ישנים, בעוד WinJS מכיל קוד שאמור לרוץ רק על IE10 ומעלה, ולפיכך יכול להשתמש ביכולות המתקדמות של HTML5 ושל ECMA Script 5. זה הופך את הקוד של WinJS לפיכך ליותר יעיל. כמובן שאין שום מניעה להשתמש ב-jQuery אם רוצים כפי שנראה בפוסט עתידי, אבל בד”כ לא ממש נצטרך.

2. ספריית קונטרולים (כגון jQueryUI) – הכח הגדול של jQuery בא לידי ביטוי מלא ביכולות ההרחבה הכל כך חזקות שלה – היכולת לכתוב פלאגינים. ספריית הפלאגינים הכי נפוצה ופופולארית – jQueryUI – מספקת תמיכה להרבה קונטרולים מתוחכמים שלא קיימים בHTML רגיל, כגון אקורדיון, קונטרול תאריך, וכו’.
גם כאן, WinJS מאפשרת עבודה עם הרבה קונטרולים נוספים, בארכיטקטורה שמאוד מזכירה את jQueryUI, עד גבול מסויים. הרבה מאוד Design Patterns שמוצאים בjQueryUI, ולמעשה בכל פלאגין של jQuery, נמצא גם כאן, ורוב הזמן נרגיש די בבית.
למרות זאת, ישנם מקומות בהם מיקרוסופט בחרה לממש דברים בצורה קצת שונה, על מנת לספק תמיכה יותר טובה לכלי פיתוח כגון Visual Studio ו Blend. כפי שנראה בהמשך, המימוש השונה הזה פותח פתח לפתירת הבעיה החמורה ביותר שיש לקונטרולים של ג’אווה סקרפיט.

3. ספריית Data Binding (כגון KnockoutJS) – למי שלא מכיר, Knockout היא תשתית ל DataBinding בג’אווה סקריפט, כך שאפשר להגדיר אובייקט בג’אווה סקריפט, להגדיר HTML שקשור אליו ע”י DataBinding, ולקבל סינכרון מלא בין ה HTML לבין האובייקטים שלנו. זו תשתית נפלאה המאפשרת לממש הלכה למעשה את ארכיטקטורת MVVM (כמו MVC על סטרואידים) בHTML. ארכיטקטורת MVVM היא למעשה הסטנדרט דה-פקטו של אפליקציות ב-WPF ובסילברלייט, ו-KnockoutJS מאפשר לנו לממש את זה גם בHTML. באפליקציות גדולות זה סופר משמעותי. (יש לא מעט ספריות מקבילות כדוגמת Backbone וכו’)
גם ב-WinJS ישנה תמיכה ב Data Binding, שנראית ומתנהגת מאוד דומה לKnockoutJS, כפי שנראה בהמשך. זה לא כל כך מפתיע בהתחשב בזה שהיוצר של Knockout JS – סטיבן סנדרסון – הוא עובד מיקרוסופט.
מי שעובד הרבה בג’אווה סקפריט ועדיין לא מכיר את KnockoutJS – כל הפוסט הזה שווה את הזמן שלכם ולו בשביל זה. שווה לבדוק את אתר הבית, ועוד יותר שווה לבדוק את האתר הלימודי היפהפה וללמוד את כל הספרייה בפחות מיום.

שלושת הספריות הנ”ל מספקות תמיכה לרוב הפיצ’רים שמתכנתי ג’אווה סקריפט מיומנים התרגלו אליהם, אם כי כמובן יש רבות אחרות על אותה משבצת, והדוגמאות שהבאתי הן פשוט הספריות בהן אני משתמש הכי הרבה. אפשר לפתח עם WinJS ואפשר לפתח עם ספריות צד שלישי סטנדרטיות –זה תלוי בהעדפה האישית למרות שזה לא באמת משנה יותר מדי – ה-Design Patterns מאוד דומים.
יחד עם זאת, פיתוח בWinJS יאפשר לנו יצירת אפליקציות שנראות ומתנהגות כמו אפליקציות Metro בהרבה פחות מאמץ. בהרבה מובנים פיתוח לחלונות 8 זה ללמוד את WinJS.

ג’אווה סקריפט היא שפה עם מעט מאוד פיצ’רים, שאפשר לעשות בה הרבה מאוד. למרות שאין תמיכה רגילה במחלקות, מאפיינים למחלקות, מרחבי שמות, ציבורי/פרטי, ירושה וכו’ (classes, properties, namespaces, public/private, inheritance) בפועל אפשר לממש את כל הדברים הללו ע”י שימוש ב-Design Patterns שהופכים לאט לאט לסטנדרט. כל מפתח #C או כל שפה עילית מודרנית אחרת שלומד ג’אווה סקריפט יופתע לגלות שאפשר “לזייף” את כל זה עם ג’אווה סקרפיט.
כל פלאגין טוב של jQuery מממש למעשה את כל היכולות הללו. הבעיה היא שבמידה ושוכחים חלק מסויים ב- Patterns הללו אפשר ליצור בעיות מסוגים שונים, וגם כאן WinJS בא לעזרתינו:

4. סטנדרדיציה של Design Pattens בג’אווה סקרפיט – WinJS מכיל לא מעט מחלקות עזר העוזרות לממש את ה Design Pattens הנ”ל בצורה קונסיסטנטית וקלה יותר. במובן הזה נראה לי שהספרייה הזו עושה משהו ששום ספרייה אחרת לא עושה היום, אם כי יכול להיות שאני טועה היות ואני לא ממש מכיר את כולן. במובן הזה מיקרוסופט פשוט חושפים עבורנו את הדרך בה צוותי הפיתוח שלהם מסדרים את הקוד שלהם, ומעניין לראות כמה מהקוד הזה יהפוך להיות סטנדרט.
במאבק בין לתקן את ג’אווה סקריפט לבין להחליף את ג’אווה סקריפט – מיקרוסופט בפירוש לוקחים את הצד של לתקן את ג’אווה סקריפט – רעיון שאני קצת סקפטי לגביו אם כי חוץ מגוגל (dart) כולם הולכים לכיוונו. כך או כך זהו צעד משמעותי מאוד לקראת סטנדרדיזציה של Design Patterns קריטיים בג’אווה סקריפט.

תגים:DEV, MVVM, HTML5, win8, WinJS, dart, knockoutjs

Win8–Application folder structure on disk–חלונות 8–מבנה תיקיית האפליקציות במחשב

פורסם בתאריך Dec 14 2011, 03:08 AM על ידי eladkatz

פוסט זה הוא חלק מסדרת הפוסטים “תכנות לחלונות 8 בHTML5”.

c:\program files\Applications – התיקיה הראשית

נכון לעכשיו, כל אפליקציות מטרו מותקנות לתיקייה אחת בלבד בדיסק- c:\program files\applications . אם כי אי אפשר לדעת בשלב זה האם גם בגרסה הסופית של חלונות זה ישאר כך. לתיקייה הזו מותקנות כל אפליקציות המטרו ע”י התקנת העתקה רגילה. במבט ראשון זה נראה כמו פרצת אבטחה – האפליקציות פתוחות לחלוטין, למרות שהתיקייה עצמה לא נראית, ואין גישה אליה בצורה רגילה:

כפי שאפשר לראות, התיקייה Applications לא מוצגת, אבל אפשר לנסות לגשת אליה ע”י הקלדה בשורת הכתובת:

אולם אז תחכה לנו הפתעה – אין לנו גישה לתיקיה הזו:

איך נגשים לתיקיה

נראה קצת מעצבן שאין לנו גישה לתקייה במחשב שלנו, אבל אפשר לפתור זאת במהירות. נלחץ על security tab בחלון שקפץ לנו, ונראה את המסך הבא

נלחץ advanced

מסתבר שהתיקיה היא לא של המשתמש שלנו. נלחץ על Change, ובמסך הבא נקליד את שם המשתמש שלנו ולאחריו CheckNames:

נלחץ על OK, וננסה עוד פעם להקליד Applications בשורת הכתובת. עוד פעם תקפוץ לנו אזהרה, אבל עכשיו אם נלחץ Continue נקבל גישה לתוך התיקייה.

בשלב הזה אנחנו נגלה משהו די מטריד – קוד המקור של כל אפליקציות המטרו חשוף *לחלוטין* ואפשר לשנות אותו כאוות נפשנו. כדוגמא, זו התיקיה של אפליקציית Alarms שמאפשרת להגדיר שעון מעורר.

אפשר לראות כי קוד המקור שנמצא כאן ממש זהה לקוד שראינו בפוסט הקודם “מבנה אפליקציות”, לצד עוד כמה קבצים לא מוכרים כמו AppxSignature.p7x.
אם נכנס לדוגמא ל-default.html נוכל ממש לערוך את קוד המקור:

אם נשנה את Alarms ל Elad’s Alarms זה ממש ישנה את האפליקציה – אין שום בדיקה על התקינות של האפליקציה ועל כך שהיא לא שונתה:

האם יש כאן חור אבטחה?

רוב האפליקציות שמגיעות מותקנות בחלונות 8 בגרסה הנוכחית כתובות בHTML5, שמותקן כקוד מקור. מאוד קל להכנס ולשנות כל מה שבא לנו, אבל גם אפליקציות C# ו - C++ ניתנות לפתיחה ולשינוי. הבלוגר ג’סטין אנג’ל טען שזו פרצת אבטחה אבל האמת שאני לא באמת מבין מה חדש. אפשר להכנס לאפליקציות גם היום, וזה דבר די ידוע באבטחת אפליקציות – השרת תמיד צריך לחשוד בכל קלט שמגיע מהלקוח – זה די טריוויאלי.
בנוסף, אנחנו יודעים שאפליקציות של ה Application Store אמורות לבוא חתומות דיגיטאלית – אפשר בהחלט להניח שבגרסאות הבאות של חלונות המערכת תבדוק את החתימה הדיגיטאלית ותשווה אותה להאש כלשהו על הקבצים לודא שהם לא שונו – כך שאני לא מבין על בדיוק הוא קפץ. זה שזה לא נעשה בגרסה ששוחררה לפני שה Application Store בכלל נפתח זה הגיוני.
כשמבצעים אריזה של אפליקציה, כל הקבצים מועתקים לתוך קובץ זיפ עם סיומת appx. :

בתוך קובץ הזיפ שלהלן (זה הקובץ שיירד מה Application Store), יושבים לצד הקבצים שלנו עוד שלושה קבצים חשובים:

1. AppXManifest.xml – שמכיל את ההגדרות של האפליקציה (באיזה contracts היא משתמשת, איזו יכולות היא צריכה וכו’) כפי שראינו בפוסט הקודם.
2. BlockMap – אמור להכיל האש של כל הקבצים, וזה מה שחסר כרגע בגרסה הנוכחית שמשוחררת לציבור.
3. Signature – אותו קובץ AppxSignature.p7x שראינו מקודם – שמכיל את החתימה הדיגיטאלית של האפליקציה, מה שמוודא שאי אפשר “לזייף” אפליקציות, ושהקבצים לא שונו.

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

איפה האפליקציות שאנחנו בנינו?

האפליקציות שנוצרות כשאנחנו מריצים אפליקציה מתוך Visual Studio לא מותקנות לתוך תקיית הApplications, אלא לתוך תקיית עבודה בשם c:\users\elad\AppxLayouts (אצלי זה “elad” – בכל מחשב זה ישב תחת המשתמש הרלוונטי):

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

גם כאן אפשר לראות את כל קבצי המקור, רק שבהרצה לוקאלית ללא הApplication Store אין קובץ חתימה דיגיטאלית.

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

תגים:TECH, HTML5, win8

תכנות לחלונות 8 - מבנה האפליקציה ומודל הריצה

פורסם בתאריך Dec 10 2011, 05:42 PM על ידי eladkatz

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

פוסט זה הוא חלק מסדרת הפוסטים “תכנות לחלונות 8 בHTML5”.

מבנה הספריות

אם נפתח את כל הספריות ב Solution Explorer, נקבל את המסך הבא:

מבנה הספריות הוא כדלהלן:

1. CSS – מכיל את קבצי הCSS שלנו לאפליקציה. ישנם גם קבצי CSS של חלונות8, שמאפשרות לנו לקבל בקלות את המראה הסטנדרטי.
2. Images – מכיל תמונות. כרגע מכיל את התמונות של מסך הפתיחה ושל האריח (Tile) של האפליקציה. מסך הפתיחה זה המסך שמוצג בזמן שהאפליקציה נטענת (שווה ערך ל DOM loaded באפליקציית דפדפן רגילה)
3. JS – יכיל את קבצי הJS שלנו.
4. WinJS – JS – יכיל את קבצי הג'אווה סקריפט של WinJS – ספרייה שאנו נדבר עליה עוד רבות. WinJS נותן לנו תמיכה בהמון דברים בפיתוח לחלונות 8, וזו ספרייה שאפשר להשוות אותה בערך ל jQuery + jQueryUI + KnockoutJS כולן ביחד. על פי ברירת מחדל של הפרוייקט יש רפרפנס אך ורק ל base.js ול wwaapp.js אבל בדרך בזמן פיתוח נשתמש בכולן. חלק גדול מסדרת הפוסטים הנוכחית יוקדש להבנת הספריה הזו.

5. WinJS- CSS – יכיל את קבצי הCSS של WinJS ויאפשר לנו לתת מראה סטנדרטי של חלונות 8. מצורפים כאן שני קבצי CSS – אחד לכל Theme של חלונות – כהה ובהיר.
6. בספריה הראשית נמצא עוד קובץ אחד חשוב מאוד – package.appxmanifest שזה קובץ XML שמכיל קונפיגורציה של האפליקציה.
אם נלחץ עליו לחיצה כפולה נקבל את המסך הבא:

נחזור להגדרות האלו כאשר נרצה לקבוע Contracts שאנו רוצים להשתמש בהם, כדוגמת חיפוש וShare. (תחת הלשונית Declarations)
בנוסף, תחת הלשונית Capabilities נוכל להצהיר על יכולות HTML5 שאנו מבקשים להשתמש בהן, כדוגמת גישה למצלמה, GPS וכיוצא בזה:

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

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

1. הקבצים של האפליקציה יושבים בתוך המחשב, ולא מורדים מהאינטרנט (למרות שאפשר לגשת לאינטרנט להוריד עוד מידע – כמו כל אפליקציה רגילה).
2. אפליקציית ווב רגילה רצה בתוך פרוסס משלה בתוך לשונית (tab) בדפדפן. כל לשונית רצה בפרוסס משלה.
אפליקציית מטרו לעומת זאת, רצה בתוך AppContainer שמקביל כמעט אחד לאחד לפרוסס של של הלשוניות (tab-ים) בדפדפן. לפרוסס הזה קוראים wwahost.exe והוא מכיל בתוכו את המנוע הרגיל של IE10.
3. לקוד שרץ בתוך הדפדפן יש גישה ל”Web Platform” – זאת אומרת כל ה API הרגיל של הדפדפן, לדוגמא document.getElementById.
לקוד שרץ בתוך הAppContainer לעומת זאת, בנוסף לגישה לAPI הרגיל של הדפדפן, יש גם גישה לWindows Runtime – או בשמו המקוצר – WinRT – וכך הוא יכול לגשת ל API הראשי של חלונות.
4. כשמריצים את האפליקציה- אם נפתח את מנהל המשימות (Task Manager) של חלונות 8 (ctrl + shift + esc), נראה את המסך הבא:

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

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

תגים:DEV, HTML5, win8, WinJS

SDP11 - המצגת של ההרצאה על ממשק המשתמש של חלונות 8 - win8 - Understanding Metro UX

פורסם בתאריך Dec 06 2011, 10:27 PM על ידי eladkatz

כנס סלע SDP11 עדיין בעיצומו וממש כיף לראות את ההיענות הגבוהה של האנשים. נרשמו יותר מ 800 (!) איש לכנס ולמעשה נמכרו כל הכרטיסים… חלק מגיעים ליום הראשון – לחשיפה לחלונות 8, וחלק מגיעים לימי הלימוד שלאחריהם (20 ימי tutorial מלאים על נושאים חמים בפיתוח).

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

ציוותי הIT שלנו עדיין עובדים על ההקלטות, ובתקוה בימים הקרובים אוכל להעלות את ההרצאה המלאה בוידאו. לכל מי שעדיין סקפטי ביחס לכמה שחלונות 8 משמעותי – שווה לחכות Smile

Win8 - Understanding Metro

View more presentations or Upload your own.

תגים:TECH, win8, sdp11, metro

SDP11- המצגת, הקוד והלינקים להרצאה על ג'אוה סקריפט מתקדם - Advanced JS - KnockoutJS, ScriptSharp and Dart

פורסם בתאריך Dec 06 2011, 09:44 PM על ידי eladkatz

תודה לכל מי שהגיע היום להרצאה המשותפת של גיל פינק ושלי על Advanced JavaScript.
אני יכול להעיד מהצד שלי שיום כזה יכול להיות איכותי רק אם המשתתפים מבינים את החומר לעומק, והיה לי מאוד כיף עם השאלות שהועלו בכיתה.

כיסינו בכמה שעות המון חומר,
1. jQuery
2. jQuery MVC
3. Knockout JS
4. Script#
5. Dart

כפי שהבטחתי אפשר לראות את המצגת כאן:

JS - Knockout and ScriptSharp

View more presentations or Upload your own.

ואת הקוד שהדגמתי בכיתה כאן:

שווה מאוד לבדוק את התיעוד של KnockoutJS – התיעוד הכי טוב שאני מכיר אונליין לספרייה כלשהי.
בנוסף, שוה לראות את דף הפרוייקט של ניקיל קותארי של Script# בבלוג שלו, ואת דף הפרוייקט בגיטהאב ואת הדף המתעדכן של גוגל על Dart.

את התוסף של Script# ל Visual Studio אפשר להוריד מכאן.

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

תגים:DEV, JS, scriptsharp, dart, knockoutjs, sdp11

איזה דפדפן הכי מהיר והכי טוב? הדפדפן הכי מושמץ הרבה יותר טוב ממה שאתם חושבים

פורסם בתאריך Dec 02 2011, 01:12 AM על ידי eladkatz

מי הכי מהיר?

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

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

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

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

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

האנימציות יותר חלקות בצורה משמעותית בIE, ונראות הרבה יותר איכותיות. עם כל הכבוד לעוד 4 מילי-שניות בטעינה של דף – האתר שלי מתנהג יותר טוב ב-IE. הנקודה החשובה ביותר מבחינת מהירות זה המהירות של המנוע של ג’אווה סקריפט שמאחורי הקלעים (שאחראי בין השאר על האנימציה).
גם כאן, הנושא נטחן עד דק עם מבחנים שמודדים מיליארד פרמטרים במהירות המנוע. כמאמר הידוע, יש “יש שקרים רגילים, יש שקרים ארורים, ויש סטטיסטיקה” – גם כאן – אני לא מבין גדול בבנצ’מרקינג (Benchmarking) של תוכנה – אבל מבחן המציאות הכי רלוונטי הוא jQueryUI.

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

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

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

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

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

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

תמיכה בסטנדרטים

לכאורה, תמיכה בסטנדרטים היא הנקודה החלשה והכי מבוקרת של IE. אז זהו שלא.

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

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

כדוגמא שנתקלתי בה בזמן האחרון – תלת מימד;

יש מספר טכניקות מתחרות ליצירת אפקטים תלת מימדיים בHTML5: שימוש בCanvas3D, שימוש בCSS3, ו WebGL.

לאחרונה פיתחתי בסלע רכיב בתלת מימד בHTML והייתי צריך לבדוק באיזו טכנולוגיה להשתמש. CSS3 לא מאפשר תלת מימד אמיתי אלא רק הצגת אלמנטים דו מימדיים במרחב תלת מימדי בצורה די פרימיטיבית. זה מספיק ללא מעט אפקטים, אבל זה לא תלת מימד אמיתי.
Canvas3D וספריות דומות, זה מימוש של ספריית תלת מימד בJavaScript מעל Canvas. ו- Canvas לא באמת תומך בתלת מימד, אלא רק בגרפיקה דו-מימדית. הספריות האלו משתמשות בהרבה מאוד טריקים והרבה מתמטיקה בשביל להציג תלת מימד, והביצועים (שימוש בCPU לדוגמא) מורגשים מאוד. בשביל 500+ פוליגונים המצב נהייה בעייתי, במיוחד אם אתה רוצה שטאבלטים יצליח להריץ את זה (זו הייתה הדרישה בפרוייקט)

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

מגניב, לא? רק שIE לא תומך בזה.

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

אני לא חושב שIE יותר טוב כאן מכרום, או ההפך. כל חברה בוחרת בטקטיקה משלה, ושתיהן לגיטימיות.

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

מה הסיפור של IE6?

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

רק שזה די הגיוני האמת. IE6 הוא פרימיטיבי, היות והוא דפדפן בן 10 שנים… להשוואה, זה הפלאפון שהיה לי לפני 10 שנים:

לא באמת פייר להשוות את הסמסונג המנוח הזה לסמסונג S2, נכון?

IE6 לא תמך בסטנדרטים של W3C בכלל. מיקרוסופט די עשו מה שהם רוצים, ולא ממש הקשיבו למה שיש לW3C להגיד.
זה אולי מעצבן אותנו היום, אבל אם נחזור 10 שנים אחורה – בעולם בו IE שולט על 90% מהשוק לא הייתה משמעות לסטנדרטים שועדה כלשהי קובעת…

(אחוז השוק של אקספלורר ב15 שנים האחרונות)

מה פתאום שועדה כלשהי תקבע סטנדרטים לדפדפן שהוא דה-פקטו הסטנדרט? המון פיצ’רים של HTML נקבעו בשטח. מיקרוסופט הוסיפו פיצ’ר, והW3C הוסיפו אותו לסטנדרט בדיעבד. כמעט כל הפיצ’רים אז התחילו ע”י מיקרוסופט או נטסקייפ, כשהW3C מוסיפים את מה שתפס לסטנדרט בדיעבד.
אף אחד לא חשב שזה משמעותי ב2001. רק ב2005 אני התחלתי להיות מודע לראשונה לסטנדרטים, וזה היה כשדפדפן שבהתחלה עצבן אותי מאוד בשם פיירפוקס התחיל לתפוס נתח שוק. בהתחלה לקח לי זמן להפסיק להאשים את פיירפוקס ולהתחיל להאשים את IE. הרי פיירפוקס עובד על פי הסטנדרטים של W3C, וIE לא, אז IE אשם, לא?
היום כשסטנרטים נהיו כל כך חשובים אז נראה שהתשובה היא בבירור כן, אבל ב2005 אני לא בטוח שזו תשובה נכונה. אם 90% מהשוק מריץ IE, אז IE זה הסטנדרט, ואם קרן מוזילה היקרה הייתה בוחרת להיות פחות ייקית ויותר פרגמטית, היא הייתה מפתחת לפי הסטנדרטים דה-פקטו. מי שייצר את בעיית תאימות הדפדפנים זה פיירפוקס, לא IE. אם פיירפוקס היה מתנהג כמו הסטנדרט דה-פקטו היו נחסך לנו כזה כאב ראש אדיר!

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

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

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

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

תגים:OFFTOPIC, TECH, HTML5, web-standards

אלעד כץ | Elad Katz

לגו של גדולים

תגיות

ארכיון

על הבלוג

ניווט

December 2011 - Posts

וידאו הרצאת המליאה של כנס SDP 2011–להבין את חלונות 8 וממשק מטרו–חלק 1

תכנות לחלונות 8 - יצירת קורא RSS חלק ראשון

שימוש ב Unity באפליקציית ווב - איך לרשום רכיבים כסינגלטון בצורה נכונה פר בקשת HTTP

תכנות לחלונות 8 - מבנה WinJS

מבנה הקבצים של WinJS

מבנה מרחבי השמות

תכנות לחלונות 8 - מבוא ל WinJS

מה זה WinJS ?

Win8–Application folder structure on disk–חלונות 8–מבנה תיקיית האפליקציות במחשב

c:\program files\Applications – התיקיה הראשית

איך נגשים לתיקיה

האם יש כאן חור אבטחה?

איפה האפליקציות שאנחנו בנינו?

תכנות לחלונות 8 - מבנה האפליקציה ומודל הריצה

מבנה הספריות

SDP11 - המצגת של ההרצאה על ממשק המשתמש של חלונות 8 - win8 - Understanding Metro UX

SDP11- המצגת, הקוד והלינקים להרצאה על ג'אוה סקריפט מתקדם - Advanced JS - KnockoutJS, ScriptSharp and Dart

איזה דפדפן הכי מהיר והכי טוב? הדפדפן הכי מושמץ הרבה יותר טוב ממה שאתם חושבים

מי הכי מהיר?

תמיכה בסטנדרטים

מה הסיפור של IE6?