ליקוטי שיבולים

הבלוג הזה הוא תוצאה של שיטוטי ברשת במסגרת עבודתי כמפתחת קוד לאינטרנט, ביחידת טכנולוגיות אינטרנט במו"פ של רשת אורט. כאן אני כותבת על מאמרונים שמצאתי ברשת במגוון רחב של תחומי פיתוח לאינטרנט: החל מכתיבת קוד צד-שרת (אצלנו מפתחים בעיקר ב-#C וב-ASP.NET), עבור בכתיבת קוד צד-לקוח (JavaSciprt, CSS, HTML), וכלה בעניינים חוצי קוד - שמישות, נגישות, התאמה לדפדפנים.

לאה כהן

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

for (int i = 0; i < cards.Length; i++)
{
    int n = rand.Next(cards.Length);
    Swap(ref cards[i], ref cards[n]);
}

ג'ף אטווד קורא למתודה הזו "מתודה נאיבית", ובהמשך הפוסט שלו הוא מראה שיש בה כשל הסתברותי. יש פרמוטציות (שינויים) מסויימות שההסתברות אליהם גבוהה יותר, ולכן השינוי הרנדומלי לא מחולק באופן שווה מבחינה הסתברותית.
מדוע מיצ'ל מספר לנו את זה? מפני שלפני כמה שנים הוא כתב מאמר ב-4GuysFromRolla בדיוק על זה - איך לשנות את סדר האברים במערך באופן רנדומלי - ונתן את המתודה הזו כדוגמה מוצלחת לסידור רנדומלי של אברים במערך (randomizing) מערכים...
אז מה עושים? מיצ'ל אץ-רץ למאמר הישן, וכתב שם אזהרה לגבי המתודה, עם קישור למאמר חדש שכתב , ובמאמר החדש הוא מסביר את הכשל ההסתברותי של האלגוריתם הנאיבי, ונותן פתרון רנדומלי באמת.
אפשר לבחור לקרוא את המאמר החדש של מיצ'ל, או את הפוסט הנוכחי של מיצ'ל, או את המאמר המקורי של אטווד , בכולם מוסבר בפירוט מדוע המתודה הזו אינה מוצלחת מבחינה הסתברותית. אני אחסוך את התיאורים הפילוספיים והגרפיים ואכתוב במילים בלבד, תוך מתן דוגמה על מערך בן 3 אברים (דוגמה הניתנת בכל המאמרים הנ"ל). בסוף הפוסט אכתוב מה הייחוד של כל אחד מ-3 המאמרים הנ"ל, וגם מה מעניין במאמר המקורי של מיצ'ל: 
אם רוצים לשנות מיקומים של איברים במערך בן n איברים, יש nⁿ אפשרויות של מיקומים בסה"כ (כי לכל איבר יש n מקומות שבהם הוא יכול להיות ממוקם; ישנם n איברים, אז בסה"כ מספר האפשרויות הכולל למיקומים חדשים הוא nⁿ). אבל למערך בן n איברים יש רק !n) n עצרת) פרמוטציות אפשריות.
[פרמוטציות הן סידורים שונים. למשל: הסדר הראשוני של איברים במערך בן 3 אברים הוא [0,1,2] . זוהי פרמוטציה אחת. אם נחליף את שני האיברים הראשונים זה בזה, הסדר החדש יהיה [1,0,2]. זוהי פרמוטציה נוספת. פרמוטציות אפשריות נוספות הן [2,1,0];  [0,2,1];  [1,2,0];  [2,0,1]. זהו. בסה"כ מצאנו 6 (3 עצרת) פרמוטציות אפשריות למערך בן 3 איברים].
אבל, אם  nⁿ אינו מתחלק ב-!n, אזי בהכרח חלק מהפרמוטציות תחזורנה על עצמן יותר מאחרות, ולכן הרנדומליות היא מוטה מבחינה סטטיסטית. בשני המאמרים ישנם תיאורים גרפיים של הפרמוטציות השונות ואיך להגיע אליהן, וגם גרף המראה את החלוקה הלא-שווה של ההסתברות לפרמוטציות (יוצא שהפרמוטציות [0,2,1];[1,0,2]; ו-[1,2,0]; הן סבירות יותר מה-3 האחרות).
מיצ'ל גם מייחד חלק בפוסט שלו לשאלה עד כמה ההסתברות המוטה הזו היא באמת בעייתית. המסקנה היא שצריך לדו כל מקרה לגופו, ולראות אם באמת נזקקים בו לרנדומליות טהורה. למשל: אם יש לנו אתר שהוא חנות אלקטרונית, המראה ב"חלון הראווה" שלה פריטים רנדומליים המלאי, אזי כדאי שהרנדומליות תהיה טהורה, מפני שאחרת חלק מהמוצרים יוצגו יותר פעמים ממוצרים אחרים. אבל אם למשל יש לנו אלגוריתם רנדומלי לבחירת הציטטה היומית - לא נורא אם חלק מהציטטות תופענה יותר מאחרות.
הפתרון שאטווד - ובעקבותיו גם מיצ'ל - מציע במקום האלגוריתם הנאיבי, נקרא אלגוריתם הערבוב של ייטס ופישר, והוא כרוך בתיקון קל בקוד שכתבנו למעלה:

for (int i = cards.Length - 1; i > 0; i--)
{
    int n = rand.Next(i + 1);
    Swap(ref cards[i], ref cards[n]);
}

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

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

נראה שפחות ופחות מתכנתים קוראים ספרי מחשבים. אני יכולה להעיד על עצמי שאת רוב הידע שלי אני רוכשת ע"י קריאת בלוגים ומאמרים. אמנם מפעם לפעם (זה יוצא פעם בשנה בעצם - לכבוד יום הולדתי) אני מבקשת שיקנו לי במתנה ספר על תכנות. בשנה שעברה זה היה The Pragmatic Programmer (המוצלח והמומלץ מאד), והשנה זה Code Complete (שטרם קיבלתי אותו בגלל שביקשתי אותו מהצוות, ובצוותנו יש מסורת שלפיה אי אפשר לקבל מתנה אם לא עברו לפחות 3 חודשים מאז היומולדת...). שני הספרים האלה לא מלמדים משהו ספציפי בתכנות: לא איך ליישם תרשים זרימה; לא 0 דרכים שונות למיון מערכים, או איך לתכנת בשפה מסויימת. שני הספרים האלה הם תאורטיים, ומדברים על תכנות באופן כללי: איך לכתוב קוד שיהיה ברור לקריאה, איך לתכנן וליישם פרוייקטים בתכנות, ובאופן כללי איך להיות מתכנת מעולה. ומדוע אינני קוראת ספרים המלמדים טכניקה ספציפת, למשל ASP.NET? בשורה התחתונה - מפני שהטכנולוגיה מתקדמת מהר יותר ממהירות הוצאת ספרים.
סקוט מיצ'ל כתב פוסט על ספרי מחשבים שמלמדים טכניקה ספציפית, אבל לא מצד מי שקורא, אלא מצד מי שכותב. מיצ'ל כתב ספרים בנושאי ASP ו-ASP.NET, ובפוסט שלו הוא מדבר על הרעיון של הוצאת מהדורות נוספות של ספרים. הוא משווה את נושא המהדורות בספרי מחשבים, למהדורות בספרים לימוד במקצועות אחרים (כמו מתמטיקה), ומגלה שיותר כלכלי להוציא ספרים רגילים. וכל כך למה? הוא מתאר את תהליך הוצאת מהדורה נוספת ע"י סדרת הצעדים הבאה:

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

מיצ'ל מספר שלמרות שכתב 7 ספרים בנושאי ASP ו-ASP.NET, לא היו לו הזדמנויות רבות לעבוד על מהדורות שניות. האתגר בטכנולוגיות מחשבים הוא שהן משתנות בצורה כל כך קיצונית באופן כל כך מהיר, ש"מהדורה שניה" כבר מתייחסת לטכנולוגיה לגמרי אחרת עם מאפיינים חדשים לגמרי, המצריכים לשכתב לחלוטין את המהדורה הקודמת. הוא מתאר בפירוט (ואני חוסכת לכם את זה) את השינויים שעברו על ASP.NET, ולמה אי אפשר היה כמעט לכתוב מהדורות שניות לספרים בנושא הזה. הוא מסיים את הפוסט הזה במשפט מפוסט ישן שלו (משנת 2003): If your dream is to become a rich man, don't write computer trade books...

אז מה לקרוא, אם בכלל? כזכור, כתבתי כאן לא מזמן על stackoverflow, שהוא מיזם המסתמך על זה שמתכנתים לא קוראים. אבל כמובן שלא ניתן להניח ששני היזמים עצמם - ספולסקי ואטווד - אינם קוראים. להפך - לא זו בלבד שהם קוראים הרבה, הם גם ייחדו את פודקאסט מס' 12 להמלצות על ספרים למתכנתים. הם ביססו את ההמלצות על רשימת קריאה שהחברה (company, לא girlfriend) של ג'ואל נותנת למי שמשתתף בתכנית האימון למנהלי תוכנה שלה. אז אפשר פשוט לעבור על רשימת הקריאה הזו. ואפשר גם להאזין לפודקאסט באותו זמן, ולשמוע מה יש לשני החבר'ה האלה לומר על כל אחד מהספרים. ומי שאין לו זמן, יכול להכנס לתקציר של הפודקאסט כדי לראות רשימה של 8 הספרים ההכרחיים. לאטווד יש גם פוסט על זה שמתכתנים לא קוראים, עם רשימת המלצות משלו, ועם קישור ל-LibraryThing שהוא דבר חמוד כשלעצמו. אני מתכוונת להוסיף ל-wishlist שלי באמאזון כמה ספרים מהרשימה הזו. "כן נזכה לשנה הבאה..."

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

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

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

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

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

שיהיה לנו יום הולדת שמח!

1. אפשר לראות את עץ ה HTML לצד ה CSS המופעל על הפריט הנוכחי
2. יש כלי inspect שבעזרתו ניתן לבחור אלמנטים בדף ואז לראות את ה HTML וה CSS שלהם (כמו ב firebug)
3. ניתן להוסיף/לשנות attributes גם של HTML וגם של CSS. נחמד אך הרבה פחות נוח מלערוך ישירות properties של CSS. אולי בעתיד.
4. ניתן לסמן באופן מיידי את כל ה floats/positioned elements באמצעות outline
5. יש אפילו כלי לשינוי גודל חלון (לבדיקת רזולציה), כלי סרגל (מאוד נוח!), וכלי לדגימת צבע. בכלים האלה אני אישית לא משתמש כי את האתר עצמו אני מפתח ב FF ושם יש כלים נוחים לא פחות לעשות את הדברים הללו. כאמור,עבורי ה IE Developer Toolbar נועד לדבג בעיות שונות ומשונות באקספולרר.
6. עוד משהו חשוב מאוד שישנו זאת האפשרות לראות (ב CSS properties) האם לאלמנט מסוים יש hasLayout. זוהי תכונה פנימית של אינטרנט אקספלורר שגורמת להרבה כאב ראש מצד בוני אתרים, ולפעמים מאוד מאוד עוזר לדעת האם לאלמנט מסוים יש hasLayout או לא.

לפעמים אפליקציות צריכות לעשות מניפולציה על תאריכים וזמנים. למשל: לדעת כמה ימים יש בחודש מסוים, לחשב הפרש בין שני תאריכים. נראה שמצד הקוד בצד השרת אפשר לבצע את המניפלוציות האלה, אבל לפעמים אנחנו צריכים לבצע אותם כבר בשלב ה-client. כלומר, יש צורך בפונקציות JavaScript שתטפלנה בנושאים הללו. אך אובייקט ה-Date ב-JS אינו מכיל פונקציות לכל החישובים האלה. פתרון אחד יכול להיות לכתוב פונקציות באפליקציה שלנו שתחשבנה את החישובים האלה. אבל פתרון יותר מערכתי יהיה להרחיב את אובייקט הData של JS - זה גם הופך את הקוד ליותר קריא, ובכלל יש בזה כל היתרונות של תכנות מונחה עצמים.
המאמר הבא מתאר איך לייצר פונקציות שעושות את המניפולציות דלעיל, וגם: איך להוסיף ימים לתאריך מסוים, איך להציג את שמות הימים במילים, ועוד. אפשר להעתיק משם את מה שצריך, או פשוט להוריד קובץ JS עם כל המתודות המתוארות במאמר.
עוד מאמר המתייחס לתכנות JavaScript מדבר על כך שאוסף אינו מערך (A collection is not an array). מחבר המאמר מצר על כך שאוסף אלמנטי ה-DOM (הידועים גם בכינויים NodeList) מהווים אוסף ולא מערך, למרות שמכתנתים מתחילים לפעמים טועים ומתייחסים אליהם כמערך. הנקודה היא שאפשר להפוך אוסף למערך, והמחבר מראה קוד קצר ונעים לקריאה שעושה את הפונקציה הזו. רק צריך לזכור שכשהופכים את ה-Nodelist למערך, מאבדים את המאפיינים של אוסף, אבל זה לא ממש משמעותי (הסבר במאמר), וגם מאבדים את ה"חיות" של ה-Nodelist. ה-Nodelist מתעדכן לפי השינויים המתרחשים ב-DOM, ואילו המערך מהווה הנצחה של מצב מסוים של ה-DOM ללא יכולת עדכון.
המאמר האחרון שאדבר עליו בפוסט הזה מדבר על טכניקה לשיפור בביצועי דף ה-HTML בעזרת Lazy Loader. כידוע, רווחות היום ספריות JS לרוב - כמו Prototype, Dojo, YUI ואחרות - המציעות מגוון חוויות משתמש עשירות. למרבה הצער, מי שמשלפ את המחיר הוא המשתמשים. כל קובץ JavaScript שיש לטעון לדף מהווה קשר חדש לשרת, כל קשר חדש כזה משמעותו עוד מידע, וכל זה קורה לפני שהמשתמש בכלל רואה את הדף. למרבה השמחה יש דרך טובה יותר לבצע דברים, והיא - טעינת חלקים של הדף רק כשהמשתמש מבקש אותם. המטרה היא לדחות טעינת קבצי JS עד שצריכים אותם. לדעת המחבר, Lazy loading הוא יישום פרקטי של ה- Proxy Design Pattern . במאמר יש שלוש הדגמות של יישום ה-Lazy loader: אחד יישום עצמאי, כלומר כל קוד ה-JS שצריך להכתב כדי ליישם את השיטה הזו; יישום בעזרת ספריית Dojo; ויישום בעזרת YUI. המחבר מסיים בכמה אזהרות על חסרונות.