מחשבות, מחשבים, ושאר דברי בלע

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

הסיפור הוא שנתקלתי באתר או שניים שדרשו כתובת openid, ולא ממש התחשק לי לפתוח זהות openid באתר צד שלישי, הרי כל הנקודה בopenid למול שרותים כמו פספורט של מייקרוסופט (זצ"ל) היא שopenid הוא מבוזר ולא תלוי בספק מסויים.
חוץ מזה, אני מעדיף לשמור את הזהות שלי קרובה לבית - או אפילו.. בבית:
את שרת הדואר, שרת הJabber ועכשיו שרת הopenid אני מריץ מהמחשב בסלון.
כמו הרבה אימיילי TODO אצלי בתיבה, האימייל הזה נשכח, עד שקראתי פוסט על openid שכתב ניצן.

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

הקישקוש בסיסמא הוא גיבוב md5 של username:phpMyID:password, יש הרבה דרכים לחשב אותו, למשל:

(אני בטוח שמשתמשי חלונות ימצאו דרך לחשב md5 בחלונות).

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

אז עכשיו כתובת הopenid שלי היא http://omry.yadan.net , כתובת חביבה שאפילו אני אזכור ;).

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

FireStats 1.5 נכנס בשעה טובה לשלב הבטא עם השחרור של 1.5.0-בטא.
בין השינויים הגדולים:

ועוד הרבה.
דף הNew and noteworthy מכיל רשימה יותר מלאה עם תצלומי מסך, ויומן השינויים מכיל רשימה מפורטת.

במסגרת מקצה אופטימיזציות לFireStats מימשתי מנגנון נוסף לקליטת כניסות.
המנגנון הרגיל בו כולם משתמשים היום בודק שהכניסה לא צריכה להיות מסוננת (כניסה של רובוט ידוע או IP מסונן למשל), ומכניס את הנתונים בצורה מנורמלת.
נירמול בסיס נתונים נועד למנוע כפילויות, מה שעוזר במניעת אנומליות ובחיסכון במקום. בFireStats הנרמול מתבטא בכך שכל כתובת נשמרת פעם אחת בטבלאת הURLים, כל UserAgent בטבלאת הUserAgents וכדומה. כאשר מכניסים את הנתון העיקרי של כל הכניסה, משתמשים במזהה של כל נתון מנורמל.
המשמעות של זה בזמן הכנסת הנתונים היא כזו:
הגיעה כניסה עם כתובת מסויימת, מפנה מסויים ודפדפן (UserAgent) מסויים. לכל אחד מהנתונים האלו מבצעים פחות או יותר את סדרת הפעולות הבאה:
הכנס לטבלא הרלוונטית עם INSERT IGNORE, מה שמונע שגיאה במקרה שהנתון כבר נמצא שם (הטבלאות מוגדרות לא לקבל רשומות כפולות).
בדוק מה המזהה של הנתון שהכנסנו (אם הוא נכנס, אז זה יהיה מזהה חדש, אם לא זה יהיה המזהה שנבחר בפעם הראשונה שהכנסנו את הנתון לטבלא).
לבסוף, הכנס שורה לטבלאת הכניסות תוך שימוש במזהים שמצאנו בצעדים הקודמים.
זה קצת יותר מורכב מזה כי גם צריך לזהות ולסנן כניסות מסויימות כאמור.

כל התהליך הוא איטי למדי.
יצרתי קובץ CSV עם 100,000 כניסות (מfirestats.cc) והשתמשתי בו למדידת הביצועים:
בשיטה של הכנסה מנורמלת של כל כניסה, הקצב מתחיל די לא רע עם 80 כניסות לשניה, אבל ככל שבסיס הנתונים מתמלא הוא יורד עד שמתייצב על 7-8 כניסות לשניה.
למרות שקצב כזה בהחלט מספיק לכל בלוג מצוי, הוא ממש לא מספק לאתרים רציניים יותר או לבלוגיות עתירות בלוגים.

כשהוספתי תמיכה בWPMU בFireStats 1.4, חזיתי (חודשים לפני שביצעתי את המדידות) שקצב הכניסות יכול להיות בעיה בבלוגיות והוספתי שיטה חדשה לקליטת נתונים.
במקום לקלוט את הנתונים בצורה מנורמלת, הנתונים נקלטים לטבלאת כניסות ממתינות בצורה לא מנורמלת עם INSERT DELAYED. המשמעות של הDELAYED היא שבסיס הנתונים מכניס את הנתונים בזמנו הפנוי, ולא מחזיק את הקורא עד שהנתון הוכנס ממש.
עדיין צריך לנרמל את הנתונים, ולכל כתבתי סקריפט PHP פשוט שעובר על הכניסות הלא מנורמלות בטבלא אחת אחת, ולכל אחת קורא לפונקציה הרגילה שקולטת נתונים ומנרמלת אותם, ולבסוף מוחק את הכניסה מטבלאת הכניסות הממתינות. (מנהל המערכת אחראי לדאוג שהסריפט ירוץ בפרקי זמן סבירים, למשל באמצעות cron).
אני שומע אתכם צועקים: כן, אבל זה יהיה איטי לפחות כמו קודם, אם לא יותר!
זה נכון, אבל לפחות זה מאפשר לתזמן את העיבוד של הכניסות לזמנים פחות עמוסים כמו הלילה.
חיסרון נוסף הוא שהמשתמשים כבר לא מקבלים את הנתונים בזמן אמת, אלא נתונים שנכונים נכון לזמן העיבוד האחרון של הכניסות בטבלאת הממתינים.

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

הצעד הבא הוא כמובן לשפר את הביצועים של העיבוד הנ"ל.
כבר מהרגע הראשון שכתבתי אותו, היה לי ברור שדרושה פה אופטימיזציה רצינית, והיה לי גם ברור שהיא תהיה מסובכת.
האופטימיזציה מתבססת על התובנה הבאה:
בתוך קבוצת כניסות שנקלטו בפרק זמן מסויים, יהיו חזרות רבות מאוד של כתובות, מפנים ודפדפנים.
מה אם במקום לטפל בהם אחד אחד, נטפל בהם בקבוצות? נניח 1000 כניסות בכל קבוצה?
במקום 1000 כתובות ו1000 מפנים, יהיו לנו משהו כמו 300 כתובות (שכוללים מפנים).
במקום משהו כמו 1000 דפדפנים יהיו לנו משהו כמו 50 או 100 דפדפנים.
עכשיו נצטרך להכניס את כל מה שחדש לבסיס הנתונים, לחלץ את המזהים שלהם, ולבסוף להכניס את הכניסות עצמן תוך שאנחנו משתמשים במזהים מקודם, רק שהפעם נכניס 1000 כניסות במכה במקום כניסה אחת.
המשמעות של זה היא בעצם לממש את הפונקציה שמכניסה כניסה בודדת - אבל לרוחב, כך שתהיה ברוחב של k כניסות (קבוע כלשהו).
המימוש של זה מורכב, ולמעשה לקח יותר מפי עשר שורות קוד מהמימוש התמים הקודם, אבל הביצועים סוכר:
מעיבוד של 8 כניסות בשניה, עליתי לעיבוד של 600 כניסות לשניה.
שיפור של פי 75!

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

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

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

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

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

נכון לעכשיו הבעיה אמורה להיות פתורה (mod_cache כובה).

אחת הבעיות שכמעט כל בלוגר נתקל בהן בשלב זה או אחר היא שהוא רוצה להעביר את הבלוג לשרת חדש, אבל לא יודע איך.
המחיר של טעות בתהליך יכול להיות בלוג מושבת לכמה ימים טובים, וכולם היו רוצים להצליח במכה הראשונה.
אבל איך אפשר להצליח במכה הראשונה, כאשר כבר בתהליך ההעברה של הבלוג אנחנו נחשפים לפגעי מזג האוויר כאשר הבלוג שלנו נמצא בו זמנית בשני מקומות?
איך אפשר לוודא שהכל עובד לפני שמעבירים באמת את הכל?
לכאורה, יש פה בעיה של ביצה ותרנגולת כי כדי לוודא שהכל עובד, צריך להעביר את הבלוג ולבדוק, אבל אז כולם יראו כל טעות שאתם עושים, ואם התהליך יקח הרבה זמן אז הבלוג לא יעבוד כמו שצריך במשך זמן ארוך.
אז איך אפשר לבדוק את הבלוג בנחת על השרת החדש, אבל ככה שרק אתם תראו אותו, וכל מי שפונה אל הכתובת שלכם יגיע לבלוג הישן?
פשוט מאוד, קובץ הhosts שנמצא בחלונות בספריה המסתורית C:\WINDOWS\system32\drivers\etc, ובמערכות יוניקס ב/etc/hosts (פה אגב אפשר לראות את הקשר בין מערכות יוניקס למערכות חלונות, נחשו מי העתיק ממי?).
הקובץ הזה מאפשר לנו לקבוע את המיפוי בין כתובות IP לבין שמות מתחם, ככה שרק המחשב שלנו יושפע.
המבנה של הקובץ פשוט מאוד:

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

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

לא לשכוח להחזיר את קובץ הhosts לקדמותו ברגע שסיימתם (או אם אתם רוצים לגשת לבלוג בשרת הישן).

בהצלחה!

ווירוסי המחשבים עברו כמה מוטאציות במהלך השנים האחרונות, כדי להתאים את עצמם בצורה אופטימלית לסביבת המחיה שלהם.
בימי דוס, כשכולם היו מעתיקים דיסקטים אחד מהשני, הווירוסים הנפוצים הדביקו את טבלאת המחיצות (MBR) של הדיסקטים, או את קבצי ההפעלה של המשחקים הפופולריים, וההדבקה התבצעה פשוט על ידי הפעלה של דיסקט נגוע, יציאה מהתוכנית והפעלה של דיסקט נקי.
זכור לרעה הוירוס DIR2 שהסתפק בהפעלה של פקודת DIR בזמן שהוא היה פעיל כדי להדביק כל מה שאפשר בספריה.
עם השיפור באבטחה של מערכות ההפעלה והשיפור האיטי במערכות האנטי וירוס, הווירוסים האלו נכחדו, והוחלפו בעיקר בווירוסים ותולעים שמתפשטים דרך חורי אבטחה בדפדפנים. הווירוסים האלו הרבה יותר טפשים מהווירוסים של דוס, ובדרך כלל קל יותר להתמודד איתם בכלים פשוטים יחסית.
התולעת הראשונה פותחה על ידי סטודנט בMIT, וניצלה חורי אבטחה ידועים במערכת המערכות יוניקס, מאז צברו התול~3
^C^C^C
——-
שלום, זהו וירוס וורדפרס הראשון.
הסיבה להדבקה נובעת מביקורכם באתר הזה
ברגעים אלו ממש המערכת מזהה את הבלוג שלכם ומדביקה אותו.
מאחר והוירוס מסוגל רק להדביק מערכות וורדפרס בטקסט הזה, אנו מבקשים - כחלק מהכבוד שכולכם רוכשים למערכת הקוד הפתוח - למחוק קבצים חשובים במחשב שלכם.
לאחר מכן, אנא הסירו קבצי מערכת קריטיים על מנת שהוירוס יוכל להפוך להיות איום אמיתי.
אנו מודים לכם על התמיכה בוירוס הקוד הפתוח ומתנצלים על אי הנוחות.
——-

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

יום שבת בבוקר
שוחררה גרסא 1.0.0 של Plugin Commander
Plugin Commander הוא תוסף לWordPress MU שמאפשר הפעלה אוטומטית של תוספים לבלוגים חדשים וכן כיבוי והדלקה של תוספים עבור כל הבלוגים.
בגרסא החדשה נוספה תכונה נוספת שחסרה בWordPress MU, והיא היכולת לשלוט על רשימת התוספים שמשתמשים יכולים להדליק ולכבות.

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

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

שחררתי בטא ראשונה של FireStats 1.4.
בין השינויים:

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

אפשר לראות את רשימת השינויים המשמעותיים (כולל תמונות!) פה.
כמו שהשם מרמז, זו גרסאת בטא. Buyer beware.

רשמו לפניכם, ב25 לאוקטובר במכללת אפקה יתקיים וורדקאמפ ישראל 2007.
הכנס מתאפשר בעיקר תודות לעבודה הקשה של טל גלילי, שהביא את זה על עצמו (מגיע לך!).
לורל מLorelle on WordPress תהיה שם כמרצה אורחת (!), ועוד הרבה אנשים מעניינים.
גם אני אהיה שם, ואקשקש קצת על FireStats (אלא אם אני אשתפן ברגע האחרון).
בקיצור, הרשמו לפני שיגמר המקום, יהיה אחלה.