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

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

לאה כהן

לפני שנה דיברתי על string builder, וחשבתי שהנושא די מוצה - מה עוד אפשר לומר עליו אחרי שהוכחנו שלפעמים הוא מהיר יותר מ-string ולפעמים לא?
אז מסתבר שלאובייקט string builder יש עוד כמה אספקטים.
ב-codeProject היה מאמר לא מזמן של מתכנת שהשתמש הרבה ב-string, וזה כמובן יצר לו בעיות של איטיות, וגם של זליגת זכרון. כדי להתגבר על הבעיות האלה הוא החליף את ה-string ב-string builder, ואכן בעיות המהירות נפתרו. דא עקא, שבעיות הזכרון לא נפתרו, והוא אפילו התחיל לקבל שגיאות system out of memory.
כזכור, כאשר אנחנו מוסיפים תוים ל-string קיים, המחרוזת הראשונית מושמדת, ונוצרת מחרוזת חדשה עם המקור+התוספת. ב-string builder לעומת זאת, מוקצה אורך ראשוני (ברירת המחדל היא 16 תוים), וכאשר מוסיפים עוד תוים למחרוזת, אם האורך עדיין פחות ממה שהוקצה אז התוים מתווספים למחרוזת המקורית, ורק אם האורך החדש גדול ממה שהוקצה - המחרוזת מועתקת ל-string builder חדש. כל פעם ש-string builder מעתיק את עצמו, הוא מקצה לעצמו אורך של פי 2 מהאורך הקודם.מסתבר שההקצאה המחודשת של פי 2 מהזכרון היא זו שיצרה בעיות זכרון אצל המחבר (אפשר לראות במאמר איך תוך 3 שניות המחרוזת הגיעה לאורך של 33.5 מליון תוים!).
הפתרון שלו היה ליצור מחלקה (class) שמחקה את העבודה של string builder, אלא שהיא מאפשרת להגדיר בכמה להגדיל את ההקצאה המחודשת. הוא מראה שם בצורה מאד יפה איך המחלקה שלו היא מהירה הרבה יותר מ-string, ואע"פ שהיא אינה מגיעה למהירות של string builder היא עדיין נמצאת באותו סדר גודל (מילי-שניות אצלו וב-string builder, לעומת כמה עשרות שניות ב-string). גם מבחינת שימוש ב-CPU ובזכרון המחלקה שלו עדיפה. כדאי לעיין קצת בתגובות, יש שם מגיב אחד שמתנגד מאד לשיטה שנקט בה המחבר.
ומאמר נוסף שפגשתי לאחרונה שגם קשור קצת לנושא, נכתב ע"י אחת מנותנות השרות במייקרוסופט ששמה הוא טס (Tess), שהבלוג שלה מטפל בענייני באגים בשרתי פרודקשן. במאמר שלה היא תוקפת את אותו נושא מכיוון אחר: איך מוצאים מה גורם לשימוש גבוה ב-CPU.
היא נותנת דוגמה לנתונים של שימוש גבוה ב-CPU, מנתחת אילו דברים יכולים לגרום לזה (יש 3: 1) לולאה אינסופית, 2) עומס גדול מדי [למשל, יותר מדי בקשות של דברים קטנים, כך שאף אחד מהדברים הקטנים אינו האשם], 3) שימוש גבוה מדי ב-Grabage Collcter), ומתארת את הטיפול באחד מהם (השלישי - שימוש גבוה מדי ב-Grabage Collcter. הטיפול בגורם הראשון הוא כמובן טיפול בלוגיקה שהובילה לזה, והטיפול בגורם השני הוא ע"י קניית חומרה נוספת ואופטימיזציה שלו). אח"כ היא מראה שם dump output שאפילו בשבילי יש שם יותר מדי 0 ו-1.... ובסוף היא מראה איך למעשה במקרה הזה כל העניין נבע משימוש ב-string לשרשור מחרוזות מאד ארוכות.
וכאן יש מאמר הרבה יותר טוב שלה בנושא, מהבחינה שהוא נועד ממש להדריך איך לעלות על בעיה של string משורשר מדי. המאמר הזה הוא חלק מסדרת הדרכות מעולה שהיא נתנה בנושאי דיבוג.

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

ובלי כמה קישורים אי אפשר, אז הנה:
אתר ישראל בת 60 עם חידות, מידע וקישורים לכבוד 60 שנה לישראל. אפשר גם להגיש בו סיפורים הקשורים לתולדות המדינה.
ואתר שמצאה בתי בת ה-9.5: http://www.galim.org.il/israel60/trivia -שאלות טריויה בנושאים הקשורים לתולדות המדינה. השאלות פשוטות ומתאימות לילדים בערך בגיל הזה, בשיטת "מי רוצה להיות מליונר" (מנסיון אישי, זה כיף גם למבוגרים. או לפחות למבוגרת אחת ספציפית....)
ולסיום, הגדה משעשעת ליום העצמאות (כן, אני יודעת שזה כבר מלפני כמה שנים. אז מה? גם ההגדה של פסח היא מלפני כמה שנים...)

יום עצמאות שמח!

אתם זוכרים שלפני כמה חודשים שיתפתי אתכם ברשימת  הפידים שאני קוראת? אז בינתיים חלו כל מיני שינויים בפידים שלי, כשהעיקרית שבהן היא חלוקה שונה של טאבים, אבל יש גם פידים שנוספו ופידים שנגרעו.
כבר כשכתבתי את הפוסטים ההם, ידעתי שרשימות הפידים שלי תעבורנה שינויים - הן בגלל שאני נחשפת לעוד ועוד בלוגים כל הזמן, הן בגלל שאופי הבלוגים לעתים משתנה וכבר לא משרת את המטרות שלי, והן בגלל שאני פשוט אוהבת לשנות מדי פעם דברים כדי שלא יהיה לי משעמם... ושאלתי את עצמי, האם בכל פעם שאשנה משהו אכתוב על זה פוסט, או שמא רק אחרי מספר שינויים, והאם בכלל זה חשוב לעדכן בבלוג שלי אילו בלוגים אני קוראת.
והנה, נטווייבז פתרו לי את הבעיה. יש להם דבר חדש שנקרא "יקום", ובו כל משתמש יכול לחשוף כל מיני דברים על עצמו - פעילויות, קשרים - דברים שלא הבנתי בכלל למה הם משתמשים ואיך משתמשים בהם. הדבר היחיד שהצלחתי להבין הוא שאפשר לייצא ל"יקום" הזה את הטאבים הפרטיים שלי בנטווייבז. וזה מה שעשיתי - יצרתי יקום משלי, וייצאתי אליו 3 טאבים: "קוד צד שרת", "קוד צד לקוח" ו"חוויית משתמש". אז מעתה היקום שלי ישקף את המלצות ה-RSS שלי, ואני אשתדל לעדכן אותו (מפני שאינני רואה אפשרות של סנכרון אוטומטי בין היקום שלי לבין הלוגאין שלי).
ועתה להמלצה נוספת - גם היא בלוג שאני מרססת אליו, אך טרם ייצאתי אותו ליקום שלי - "בין חינם לחופשי", הבלוג של רון אלמוג. רון הוא חבר בצוות שלנו, בעל ידע מופלג בתחומים שונים, ובחור יסודי מטבעו. מה שאני מאד אוהבת בבלוג שלו הוא שכשרון בוחר נושא לדבר עליו, הוא חוקר אותו מכל הכיוונים האפשריים, והפוסט שהוא כותב כתוצאה מכך הוא למעשה סיכום ממצה של הנושא. כך למשל כשהוא בודק מערכות סטטיסטיקה לאתרים, כשהוא בוחן תבניות חדשות בבלוגלי, וגם כשהוא מדבר רק על מערכת אחת, הוא נותן סקירה ממצה של אפשרויות אחרות. מומלץ בחום!
ההמלצה האחרונה בפוסט הזה אינה המלצה שלי, אלא קישור לרשימת מומלצים.
לאתר SitePoint ישנם פורומים רבים בנושאי קוד ברשת. במסגרת פורומים אלה צמחו ועלו להם משתתפים בעלי ידע רב, והם אותרו ע"י צוות SitePoint ומונו להיות ה-"גורו"-ים של האתר.כל גורו שייך לתחום מסוים, כך שישנם גורו-ים של קוד-צד-לקוח (שלושה גורו-ים: גורו HTML, גורו CSS, וגורו JavaScript); ישנם גורו-ים בתחום העיצוב לרשת (web design ו-flash). יש גם גורו-ים בתחומים שאני פחות מזהה אותם כצד החזק של Sitepoint, כמו קוד-צד-לקוח ואסטרטגיות עסקיות.  במסגרת היותם גורו-ים, הם התבקשו לתת רשימת מאמרים מומלצים ב-SitePoint, כל גורו בתחומו. כאן יש קישורים לכל רשימות המומלצים של הגורו-ים. איני יודעת אם כל הרשימות הן אכן ההמלצות האולטימטיביות, אבל לפחות בענייני צד לקוח ועיצוב ברשת אני כן מחזיקה מהם. מה גם שאפשר להשתמש ברשימות האלה כנקודת מוצא בלבד, ולהמשיך לחקור את האתר - ואת הרשת - בתחום המבוקש.

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

לאחרונה נתקלתי בסיטואציה די מפתיעה מבחינתי: צורך להציג CSS מיוחד אך ורק לפיירפוקס.
 למה מפתיעה אתם שואלים? כי בד"כ אני משתדל לכתוב קוד ע"פ סטנדרטים, ובמקרה כזה לרוב אקספלורר הוא זה שצריך טיפול מיוחד (אותו הוא מקבל באמצעות שילוב של css hacks ו conditional comments).
 הפעם נתקלתי בבעיה מאוד מעצבנת שמקורה בבאג של פיירפוקס עד גרסה 3 לא כולל:
נגיד שרוצים לעשות horizontal menu באמצעות ul list. לכאורה אין שום בעיה (עושים display:inline ל LI). ובאנגלית באמת אין בעיה.
אבל כשאנחנו כותבים בעברית ומוסיפים padding ל LI הוא מתווסף רק בצד ימין.
כל כך מעצבן! צילומי מסך:
 
בעברית:

באנגלית:
 
רואים איך הפריטים בעברית מצטופפים בצד שמאל וכל ה padding שלהם עבר ימינה? ובכן הפעם פיירפוקס טועה וכולם צודקים (ספארי, אופרה ואפילו אקספלורר האקס).
אז מה עושים? יש שתי אפשרויות:
1. בונים את זה אחרת לגמרי (למשל באמצעות float:right) בצורה שתעבוד בכל דפדפן.
2. מגישים CSS אחר לשועל האש הסורר.
 לרוב הייתי הולך על האופציה הראשונה. אבל הפעם, כיוון שמדובר בבאג של פיירפוקס, וכיוון שהאופציה הראשונה מוסיפה סרבול מיותר לחלוטין, בחרתי באפשרות השנייה.
איך גורמים לשועל לראות משהו אחר לגמרי? רוב ה hacks כאמור מיועדים או רק לאקספלורר, או רק ל"דפדפנים טובים". במקרה שלנו פיירפוקס היה ילד רע ולכן אף אופציה לא מתאימה. אנו צריכים משהו שרק הוא יראה.
אז אחרי הקדמה ארוכה קבלו את התשובה (צילום מסך בגלל אנגלית הפוכה):
 
הפתרון מתבסס על שימוש באלמנט שיש רק בפיירפוקס:  , כאשר ה-x יכול להיות כל אלמנט HTML, כמן A או TD. כל דפדפן אחר לא יבין את הכלל הנ"ל ויזרוק אותו לפח ה CSS הפרטי שלו.
כיוון שפיירפוקס 3 כאמור כבר תיקן את הבאג, אנחנו צריכים לשחזר את מה שדרסנו. זה נעשה ע"י אלמנט שיש רק בפיירפוקס 3: .
אם כן, יש גאולה.
 
אתם בטח רוצים לדעת אילו כללי CSS שמתי שם. פשוט מאוד. לפיירפוקס 2 שמתי float:left ולפיירפוקס 3 float:none. זהו.
 
את ה hack הזה מצאתי אחרי הרבה חיפושים כאן .
 
שימו לב שזה מתוך ה cache של גוגל כי הפילטר של אורט לא נתן לי להגיע לכתובת המקורית של האתר:
http://pornel.net/firefoxhack (ארבע אותיות ראשונות בעייתיות)

מקווה שנהנתם ולמדתם משהו שימושי.
 
סרג'

נגמרו הנקיונות, ואף חג הפסח חלף עבר לו. רציתי לשוב עם פוסט מעניין במיוחד, כזה שיפצה על שבועיים של יובש, אבל הנושא שלו אני רוצה להקדיש את הפוסט הזה אינו נחשב נושא מעניין כלל: בניית אתר מאובטח.
אני מתחילה לפהק רק מהמחשבה על הפיהוקים שהנושא הזה מעורר אצלכם, אבל האמת היא שגיליתי שזה בכלל לא משעמם, ולכן אסתכן בשיתופכם בכמה מאמרים שקראתי לאחרונה.
המאמר הראשון הוא זה שהתחיל לעורר את התעניינותי בנושא של אבטוח אתר, והוא מדרג את סוגי הפרצות לאתרים לפי הנפיצות שלהם. המאמר מתחיל במשפט מבהיל: ל-9 מתוך כל 10 אתרים יש פרצות (vulnerabilities) שדרכן ניתן לפרוץ לאתר, כאשר הממוצע הוא 7 פרצות לאתר (כלומר, 7 חורים דרכם יכולים האנשים הרעים להגיע למידע רגיש).
במקום הראשון, הפרצה הנפוצה ביותר היא  Cross Site scripting - XSS, המופיע בכ-70% מהאתרים. XSS קורה כשהאתר אוסף מידע מהמשתמש, והמידע מכיל תוכן זדוני (כמו למשל scriptים למיניהם). דוגמה: משתתף פורום כותב script בתוך הודעה בפורום. כאשר יעלה הפורום עם ההודעה שכתב גולש זה, הדפדפן יריץ את ה-script...
הפרצה הבאה בתור בנפיצותה היא דליפת מידע , והיא מתרחשת ב-2 מתוך 5 אתרים. דליפת מידע מתרחשת כאשר האתר - במודע או שלא במודע - חושף מידע רגיש כמו למשל: הערות בקוד, מידע על משתמש, כתובות IP פנימיות, קוד מקור.
הפרצה שנמצאת במקום השלשי היא content spoofing - הונאת תוכן, טכניקה נפוצה במזימות phishing. היא גורמת לגולש להגיע לתוכן שדומה לתוכן באתר הלגיטימי, אך למעשה מגיע מאתר בלתי לגיטימי וזדוני. ההונאה הזו יכולה להתבצע באמצעות דואל (למשל: דואל המבקש לאפס סיסמה באתר שלגולש יש בו חשבון. במקרה של הונאה, הקישור אינו מוביל לאתר הנכון, אלא לאתר הדומה לו אך נמצא בכתובת אחרת וכל מטרתו היא לגנוב את סיסמתו של המשתמש).
במקומות הרביעי והחמישי נמצאים בהתאמה - אי מחיקה של דפי אינטרנט ישנים העלולים להכיל מידע רגיש, ו-SQL injection - שיטה להחדרת פקודות SQL ל-DB, פקודות שנועדו למחוק מידע או לגנוב זהות.
שני המאמרים הבאים שקראתי נועדו למפתחים, והם מכילים הדרכות להתגוננות מפני כוחות האופל:
למאמר הראשון יש כותרת שמשרה בטחון: אפליקציות אינטרנט הן סוסים טרוייאנים להאקרים. איך אפשר להרדם בלילה אחרי כותרת כזאת?! מכל מקום, המאמר הזה מפרט סוגי פרצות באתרים, לא לפי סדר חשיבות מסויים. כמובן שישנה חפיפה מסויימת עם המאמר הקודם, אך הנה מספר חידושים:
שדות חבויים (hidden fields). מתכנתים רבים סבורים כי בגלל שמם (hidden), השדות הללו אינם גלויים ולכן ניתן לשמור בהם מידע רגיש. כמובן, כל מי שאי פעם עשה view source לדף עם שדות חבויים יודע כי הם גלויים לעיני כל מתבונן, ולכן יש להזהר מאד בשימוש בהם כמאחסני מידע.
הרעלת עוגיות. לפעמים אתרים משתמשים בעוגיות הנשתלות אצל הגולש, ושומרים בהם מידע כגון שם משתמש, סיסמה, מספר חשבון וכד'. יש לדעת להזהר מגולשים זדוניים העלולים לשנות את המידע המאוחסן בעוגיות ובכך לגשת למידע לא-להם.
אז מה צריך לעשות כדי להגן על האתר? המאמר הבא מלמד את המתכנתים כמה וכמה כללים:
1) להיות חשדניים כלפי כל מידע המגיע מהגולש. עליהם לסמוך רק על מידע שהם שולטים בו, ומכיון שהם אינם שולטים במידע המגיע מהגולש, עליהם להתייחס לכל קלט כפוטנציאל לזדון ולכן לבדוק (באמצעות ולידטורים או באמצעים אחרים) כל קלט המגיע לאפליקציה.
2) אם האפליקציה דורשת זיהוי משתמשים, יש לכתוב את הקוד לזיהוי המשתמשים מיד בהתחלה ולדבג אותו, ולא להשאיר זאת לסוף. במסגרת כלל זה כדאי גם להזכיר שיש תמיד לתת את ההרשאה הנמוכה ביותר האפשרית לכל תפקיד, כדי למנוע אפשרות שלמשתמשים לא מורשים יהיו מסוגלים לבצע מניפולציות מסוכנות על המידע.
3) להשתדל להשתמש ב-POST במקום ב-GET.
4) דפי ASP לעתים קרובות מכילים כתובות גישה ל-DB. אמנם הקוד של דף ASP הופך להיות HTML רגיל וזה גורם למתכנתים להיות בטוחים שמה שכתוב בקוד אינו גלוי לגולש, אך ישנן לא מעט דרכים להגיע לקוד המקור של דף ASP, ולכן כדאי להזהר.
לסיכום, קצת מפחיד לגלות באיזו קלות יכולים אנשים רעים להגיע למידע, אך בו בזמן נראה כי אם מפעילים מספר תהלכי עבודה  פשוטים בזמן הפיתוח ניתן לספק הגנה די טובה לאתרינו וליישומינו.