תהליך תקינה ב w3c
בזמן האחרון אני עובר קצת על מחקר html5 - יש שם הרבה דברים יפים אך לא תמיד מובן מה רמת הבשלות של כל פיצ'ר. כשמסתכלים על מסמך תקינה בצד שמאל ישנה סימניה שמציינת את הסטטוס של התקינה אך מה אומר אותו סטטוס ?
- טיוטת עבודה (Working Draft)
- קריאה אחרונה לטיוטה (Last Call Working Draft)
- מועמד להמלצה (Candidate Recommendation)
- המלצה מוצעת (Proposed Recommendation)
- המלצה - (W3C Recommendation )
טיוטת עבודה - העבודה בתהליך, התוכן יכול להתעדכן להתחלף,או להתבטל.
קריאה אחרונה לטיוטה - מפורסמת ע"י קבוצת העבודה שאחראית על תקן מסוים בכדי לקבל משוב מבחוץ .
מועמד להמלצה - חלק מהתקינות מסובכות יותר ויתכן כי הן צריכות יותר בדיקה (עי ארגון התקינה או חברות חיצוניות) כמו בטיוטה לא ניתן להתבסס על התוכן לתקינה.
המלצה מוצעת - מייצגת את השלב הסופי של העבודה .גם כאן התוכן יכול להתעדכן להתחלף או להתבטל אך לרוב המלצה מוצעת קרובה להמלצה הסופית.
המלצה - היא התקינה של אירגון w3c שאותה ממליצים לספקי התוכנה ליישם.
בפועל יצרני תוכנה בדרך כלל רצים לפני העגלה ומטמיעים ממשקים (לפעמים גם על פי הטיוטה) וכך יוצא שהתקינה מתעצבת מאימוץ ה API בשטח.
כרום לא טוען את הדף
אם מופיע לך ההודעה הבאה
The webpage at http://www.codeinvain.com/ might be temporarily down or it may have moved permanently to a new web address.
Here are some suggestions:
Reload this web page later.
או
וכדי לצאת ממנה אתה צריך לטעון מחדש את הדף או לסגור לגמרי את הדפדפן ולפתוח מחדש יש פתרון לבעיה
בטל את "Use DNS pre-fetching to improve page load performance" בהגדרות הדפדפן
[win7] שינוי הסייר מפתיחת libraries לפתיחת computer
משהו קטן שתמיד מעצבן אותי בווינדוס 7 זה פתיחת חלון סייר חדש דרך האיקון בסרגל.
תמיד זה פותח את ה libraries , יכול להיות שלמשתמשים ביתיים זה עדיף אבל אני מעדיף לקבל את הכוננים (computer) ולהמשיך משם
לא צריך הרבה כדי לגרום לזה לעבוד , לחיצה על הספריות בחירה ב properties ושינוי ה target ל :
%windir%\explorer.exe ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
עדכון בלוג מרחוק (crossposting)
XpostCS
אחד האתגרים שנתקלתי בהם במעבר לבלוג פרטי היה להמשיך לעדכן את הבלוג הראשון שלי במערכת הבלוגים של מיקרוסופט (מה שנקרא בלעז crossposting) . כשעברתי בחרתי את וורדפרס בתור מערכת הבלוג שלי עקב תמיכתה הרבה בתוספים (שלרוב מקלים לי על תהליך הכתיבה והניהול). אחרי חיפוש ושיטוט ברשת וקצת קריאה על איך בלוגים עובדים מצאתי תוסף שמבצע את המטלה אבל בין שני בלוגים של וורדפרס. התוסף משתמש בסטנדרט MetaWeblogAPI שכמעט חופף בין וורדפרס ל CS (הפלטפורמה שמפעילה את הבלוגים של מיקרוסופט) , עם קצת מזל קצת זמן וקצת קפה הכנתי גרסה מתאימה שניתן להוריד ולהתקין ידנית. אם מישהו רוצה להרים את הכפפה ולהכניס את הפלאגין לאתר וורדפרס מוזמן בכיף.
בכל מקרה ראיתי שיש כמה בלוגרים בקהילה שבחרו לעבור לבלוגים חיצוניים ועדיין לעדכן את הבלוג המקורי שלהם , יש מצב שהתוסף יתאים גם לכם.
שיפור ביצועים על פי סטיב סונדרס
סטיב סונדרס, אשר בזמן עבודתו ביאהו היה אחרי לשיפור ביצועי האתרים, הוביל שינוי משמעותי בניתוח והבנה של זמן תגובת אתרים. במהלך עבודתו כתב סונדרס את הספר אתרי אינטרנט בעלי ביצועים גובהים ואת הכלי YSLOW שמנתח זמני טעינת תוכן בצד הלקוח ועצות לשיפור זמן הטעינה.
כחלק מתהליך בנית הקווים המנחים לשיפור הביצועים עשו סטיב וצוותו מספר מחקרים בתחום אשר שפכו קצת אור בתחום ביצועי אתרים.
משך טעינת עמוד
הממצא המשמעותי בעבודתו של סונדרס הוא שהזמן שהעמוד נבנה בצד השרת (כולל הבקשה והחזרה של ה HTML) הוא כ 10% עד 20%. שיפורי ביצועים בשרת הנם הכרחיים לשיפור יחס כמות משתמשים לחומרה, וצריכת חשמל, אך משנים במעט את זמני התגובה של אתר ממוצע. רוב זמן הטעינה עובר על טעינה וניתוח של סקריפטים (CSS \ JS) וטעינה של תמונות ומשאבים אחרים מהרשת.
גישה לזיכרון המטמון
50% מהמשתמשים מגיעים לאתר ללא זיכרון מטמון וכ 20% מכלל הצפיות נעשה עם מנגנון ריק (המחקר נעשה על אתרי YAHOO) , חווית הטעינה הראשונית הנה הרבה יותר נפוצה מהמקובל לחשוב, וצריך לתכנן את האתר בהתאם.
ניתן ללמוד על מחקרים אלו ועוד בהרצאתו.
טכניקות לשיפור ביצועי אתר
להלן נקודות למחשבה כשמפתחים שירותים בעומס גבוה:
תוכן סטאטי מוגש בצורה מהירה יותר (ובפחות עומס) מתוכן דינמי.
במידה ואפשר עדיף לעבוד עם מנגנוני מטמון שמקצרים זמני תגובה ומפחיתים עומסי חישוב, כמו הרבה בעיות בתכנון מערכות מדובר ביחס ישיר בין יכולות זיכרון ויכולות עיבוד. שמירת דפיHTML או מידע טקסטואלי (כגון XML JSON) בצורה סטאטית גם משתמש ביכולות מובנות של שרתי ה WEB ותומכים במנגנוני מדרג גדולים מאוד וגם חוסך זמן עיבוד יקר. על פי מקורות שונים ברשת מדובר בגדילה ממאות לאלפי קריאות בשנייה.
יש יותר לקוחות משרתים והם בדרך כלל במצב סרק (idel).
לכן אפשר לנצל כוח עיבוד עודף שנמצא במחשב הלקוח. טעינת ממידע בצורה גולמית (שעבר עיבוד מינימלי בשרת) וחישוב התוצאה בצד הלקוח מאפשרת הורדת עומס חישובי. גם אפשרויות של טעינה עצלה של תוכן (על פי דרישה) יכולה להקל על עבודת השרת.
כמות וגודל המשאבים משפיעה על זמן הטעינה.
עדיף לצמצם בכמות הקריאות לשרת ולהשתמש במנגנונים לצמצום כמות המידע שעובר ברשת, אם על ידי מנגנוני דחיסה ואם על ידי מנגנוני איחוד. דחיסת תוכן נעשית על ידי הפעלת מנגנוני דחיסה ברמת שרת ה WEB כגון GZIP (אשר נתמך על ידי פרוטוקול HTTP) ואם על ידי מנגנוני תוכנה שמבצעים אופטימיזציות על קוד קיים כגון jsmin או YUI Compressor או טכניקות פיתוח (שכיום דורשות יותר עבודה) כגון CSS Sprites
CAP and WEB 2.0
ההנחה כי ניתן להבטיח שניים מתוך שלושת העקרונות עקביות, זמינות וסובלנות חלוקה היא אמתית וניתן לראות עדות לכך באתרים המצליחים ביותר.התמודדות עם CAP
יש כמה אפשרויות להתמודדות עם בעיות שמוצגות על ידי CAP. הפשוטות הן:
ויתור על סבילות חלוקה
אם אתה רוצה לרוץ בלי מחיצות אתה צריך לעצור אותן מלקרות. דרך אחת לעשות זאת היא לשים הכל (כל מה שקשור ליחידה אחת או טרנזאקציה) במחשב אחד, או ביחידה אטומית אחת כמו מתלה (rack). זה לא 100% בטוח כי עדיין יכולים להופיע כשלים, אבל יש פחות סיכוי לקבל תופעות לוואי שנובעות מחלוקה. לשיטה זו יש מגבלת גדילה משמעותיות.
ויתור על זמינות
זהו הצד השני של המטבע.כאשר יקרה אירוע שמתמשך מעבר למחיצה (או צומת) אחת, השירותים המושפעים פשוט ימתינו עד עדכון הנתונים. שליטה זו יכולה להיות מורכבת למדי על צמתים רבים.
ויתור על עקביות
או, לקבל כי הדברים כי יהפכו "בסופו של דבר לעקביים". המון סתירות לא באמת דורשות הרבה עבודה כמו שניתן לחשוב (כלומר עקביות רציפה היא כנראה לא משהו שאנחנו צריכים ממילא). בדוגמת הספרים (מהפוסט הקודם) אם שתי הזמנות יכנסו לספר שקיים רק פעם אחת במלאי , הלקוח השני יקבל הודעת זיכוי על הקניה.
קפיצת בסיס (BASE Jump)
הרעיון של להיות עקבי בסופו של דבר נתמך באמצעות מה שנקרא BASE ו(Basically Available, Soft-state, Eventually consistent) ראשי התיבות קצת מאולצים אבל עדיין שימושים.
תכנון עוקף
גיא פרדון מatomikos כתב פוסט מעניין שאותו כינה "פתרון CAP (הוכחה כי ברואר שגה)", מציע גישה אדריכלית שמספקת עקביות, זמינות וסבילות חלוקה, אם כי לא ניתן להשיג את כל שלוש המאפינים באותו הרגע.
CAP – אתה יכול לבחור רק שניים
משפט CAP מתאר מערכת בעלת עם מבנה נתונים או מצב זיכרון (state) העונים על המאפיינים הבאים:
1. עקביות (Consistency) - כל לקוח של המערכת מקבל את אותם נתונים גם אם התבצעו עדכונים במקביל.
2. זמינות (Availability) - המערכת משרתת את כל בקשה של לקוחותיה.
3. סבילות חלוקה (Partition tolarance) - ניתן לפצל את מבנה הנתונים או מצב הזיכרון על פני מספר שרתים, או במילים אחרות לפצל את השירות על פני כמה צמתים ברשת.
הטענה היא שבתכנון ובניית מערכת ניתן לבחור רק שני מאפיינים מהשלושה .
להלן ההוכחה (מקור ג'וליאן בראון)
![intro[1]](http://www.codeinvain.com/heblog/wp-content/uploads/2009/11/intro1.png "CAP Intro")
התרשים מראה מערכת מחולקת אשר מכילה שני צמתים ברשת , N1 ו N2. שניהם חולקים פיסת מידע V (כמה עותקים לספר במלאי), עם הערך V0. על הצומת N1 רץ אלגוריתם שנקרא A ואנו יוצאים מנקודת הנחה שהוא צפוי, חסר באגים, ומהימן.על הצומת N2 רץ אלגוריתם דומה שנקרא B . בניסוי A כותב ערכים חדשים של V ו-B קורא ערכים של V.
התמונה למעלה מתארת תרחיש רגיל (המערכת עובדת כשורה) ,והפעולות הבאות יקרו:
1. Aכותב ערך חדש ל V (נקרא לו V1)
2. הודעה M עוברת מ N1 ל N2 ומעדכנת את העותק של V
3. כל קריאה של B תחזיר את הערך החדש V1
התמונה הזו מתארת טעות, הודעת העדכון (M) לא עברה. מכאן שבשלב 3 קריאה ל B תחזיר ערך לא עדכני.
קריאה ל A ו B יחזירו תוצאות שונות אני מקווה שכאן הבעיה כבר מובנת, נגדיל את קנה המידה לכמה מאות פעולות וזה הופך לבעיה גדולה. אם M הוא הודעה אסינכרונית אז לN1 אין דרך לדעת אם N2 קיבל את ההודעה. אפילו עם מסירה מובטחת של M , אין ל N1 דרך לדעת אם הודעה מתעכבת או שמשהו כשל בN2. הפיכת M לסינכרונית לא עוזרת כי התייחסות לסנכרון כפעולה אטומית יגרום לעקבת (latency בהעדר תרגום מתאים) וזה מפר את עקרון הזמינות. ההוכחה, באמצעות וריאציה,מראה כי אפילו במודל סינכרוני חלקי לא ניתן להבטיח אטומיות.
אז מה CAP אומר לנו ? שאם אנחנו רוצים ש A ו-B יהיו בעלי זמינות גבוהה (כלומר לעבוד עם עקבת מינימלית) ואנחנו רוצים שהצמתים N1 עד *N (כאשר * יכול להיות מאות או אפילו אלפים) יהיו בעלי סבילות חלוקה (שידעו להתמודד עם אבדון הודעות, הודעות שלא נשלחו, תקלות חומרה ותקלות תוכנה) אז לפעמים אנחנו הולכים לקבל מקרים שבהם הצמתים לא מסונכרנים וצומת אחד חושב כי V הוא V0 (עותק של ספר אחד) וצמתים אחרים יחשבו כי V הוא V1 (לא אותו עותק).
פיתוח צד שרת לשירותי רשת
![servers[1]](http://www.codeinvain.com/heblog/wp-content/uploads/2009/11/servers1.jpg "שרתים")
שבוע טוב. בצד הלקוח ראינו סט מוגבל יחסית של טכנולוגיות,דבר הנובע מחסם בסיסי - אמון. התקנת אפליקציה כתנאי לשימוש בשירות מהווה חסם גדול ומצריכה יחסי אמון בין הגולש לשירות.
בצד השרת ישנו חופש טכנולוגי גדול וישנן הרבה יותר טכנולוגיות ופלטפורמות,אך אני לא אפרט בשלב זה על כך אלא על האתגרים שעומדים בפני מתן שירות WEB 2.0.
על פי הנחתי מפוסט קודם מאפיני שירות web 2.0 ישנו שינוי עיקרי מול שירותי "WEB 1.0" והוא כתיבה. בעולם ה WEB 2.0 כל משתתף בשירות יכול ליצור תכנים, פרט "קטן"המשנה את ארכיטקטורת התוכנה בגדול.
מערכות ה WEB 2.0 נאלצות להתמודד עם מבני נתונים עם קשרים מורכבים ותצוגות מידע אישיות למשתמשים. אם ב YNET כל אחד שנכנס רואה את אותו עמוד הבית אז בפייסבוק כל משתמש מקבל עמוד בית "פרטי" ודינאמי , תהליך הקטנת העומסים באמצעות מנגנוני מטמון (cache בהעדר תרגום מתאים) הופכת למסובכת מאוד.
יתר על כך בשנים האחרונות ניתן לראות עוד מאפיין שימוש שהפך לנפוץ והוא ה"מיקרו בלוגינג" , אם בטוויטר או שורת הסטטוס בפיסבוק האתגר הטכנולוגי הוא אחד, ודומה למתואר בפסקה הקודמת אך אם דרישות מהירות רענון גבוהה לכמויות מידע קטנות.
שירות web 2.0 ברמה גלובלית דורש זמינות מלאה ,שירות בסדר גודל של פליקר או דלישס דורש זמינות מסביב לשעון. אך אמור גם להגיב בצורה ראויה להתקהלות ספונטנית - ע"י ארכיטקטורת גדילה גמישה.
למרות שהשליטה על התוכן עברה לידי המשתמשים האחריות על יחידת המחשוב נשארו בידי ספק השירות, במקרה של הצלחה הגיעו סט של אתגרים חדשים בהתמודדות עם זמינות אחידות ויכולת ביזור שעליהם נכתבה טענת CAP.
כל זאת ועוד בהמשך 
