פורסם ב

הבאג שחמק

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

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

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

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

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

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

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

—

טוב, הצלחתי אחרי שכיביתי את הפלאגין שמוסיף את הPreview pane.

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

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

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

טוב, ולסיכום – צילומסך של ממשק הניהול (בתקווה שהשוא"ש לא יעוף שוב) :

WordPress 2.7 Dashbaord

פורסם ב

שדרוג מזורז

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

פורסם ב

PHP4 מגיע לסוף החיים, אבל עדיין בשימוש של כ38% מהשרתים

שוחררה הגרסא האחרונה (ככל הנראה) בענף של PHP 4.4.
הגרסא הזו מסמנת את סוף התמיכה הרשמית בPHP4.
PHP5 כבר בחוץ במשך יותר משלוש שנים, אבל עד עכשיו האימוץ שלו היה די איטי, מסיבות של ביצה ודינוזאור:
מפתחי התוכנות לא רצו להפסיק לתמוך בPHP4 כדי לא לאבד משתמשים. חברות אירוח האתרים לא טרחו לשדרג כי כל התוכנות החשובות תמכו גם ככה בPHP4 והמשתמשים, מה איכפת להם?
בשנה שעברה נפתח אתר gophp5.org, ששם לעצמו למטרה לדחוף את האימוץ של PHP5.
הרעיון הוא שאם מסה מספיק גדולה של פרוייקטים תעבור לPHP5, ומסה מספיק גדולה של חברות אירוח תעבור לPHP5, לשאר חברות האירוח לא תהיה ברירה והן תאלצנה לשדרג או לאבד משתמשים, ואז לשאר הפרוייקטים לא תהיה סיבה להשאר בPHP4 והם יוכלו להתחיל סוף סוף לנצל את היכולות של PHP5.
בפברואר 2008 כבר היו מעל 100 פרוייקטי תוכנה שהתחייבו להפסיק לדאוג לתמיכה בPHP4 (זה לא אומר שהם ילכו וישברו את התמיכה בPHP4 בכוונה, פשוט שהם יפסיקו לדאוג שקוד חדש ירוץ בPHP4), ומעל 200 חברות איכסון שתומכות בPHP 5.2 כביררת מחדל וgophp5 טענו להצלחה והפסיקו לאסוף הרשמות.

אז למה לא לתמוך בPHP4? הנה דוגמא מאתמול:
JSON הוא דרך להעביר מבנה נתונים כלשהו לייצוג של מבנה הנתונים כאובייקט ג'אווה סקריפט, והוא אחת הדרכים הפשוטות והיעילות ביותר להעביר נתונים מקוד בצד השרת לדפדפן (שפשוט מפעיל על הטקסט שחוזר את המפסק (parser) של ג'אווה סקריפט כדי לקבל אובייקט מוכן לשימוש.
למרות שראשי התיבות של AJAX הן Asynchronous Javascript And XML, מעולם לא השתמשתי בAJAX כדי להעביר XML, למעשה אני מוצא את הרעיון מזעזע. הרבה יותר קל להעביר JSON, או אפילו קוד HTML ממש.
JSON משמש בהרבה מאוד פרוייקטים מבוססי AJAX, ומכיוון שאין בPHP4 תמיכה מובנית בJSON (אחרי הכל, PHP4 הוא בן שמונה, וJSON הוא די חדש בשכונה) צריך להשתמש בספריות חיצוניות שיודעות להעביר אובייקט PHP לפורמט JSON, אחת הספריות הנפוצות היא Services_JSON (למעשה אני משתמש בספריה הזו בFireStats).
הספריה כתובה בPHP, ולמרות שהיא עובדת נכון, היא לא ממש עובדת מהר, במיוחד כשממירים מבני נתונים גדולים (לא עצומים, משהו בסדר גודל של מערך עם 1000 אובייקטים טיפה מורכבים) לJSON.
ממש אתמול ניסיתי לשפר ביצועים של ישום PHP, אחרי חפירות גיליתי שאחד הדברים שמאטים מאוד את העסק היה המרה של תשובה לדפדפן לJSON בשימוש בServices_JSON, כשאני אומר איטי, אני מתכוון ל8 שניות.
שמונה שניות שהשרת טוחן את הCPU שלו כדי להכין תשובה ללקוח (במקרה הספציפי הזה, במקרים אחרים עם יותר נתונים זה כמובן יותר גרוע).
ברגע שראיתי את זה, לקח לי בדיוק שניה וחצי להיזכר שPHP5 תומך בJSON. בדיקה מהירה בphp.net הניבה את שתי הפונקציות הפשוטות json_encode וjson_decode. החלפתי את השימוש ב Services_JSON בקריאה לפונקציות של php5, ולא הייתי מופתע במיוחד לראות שהמרה של אותו מבנה נתונים לוקחת פתאום 40 מילישניות.
שיפור של פי 200, בזמן עבודה של כמה שניות (טוב, חוץ מלמצוא את הבעיה 🙂 )
השיפור נובע מכך שהתמיכה של PHP בJSON לא כתובה בPHP אלא בC, ולכן היא הרבה הרבה יותר יעילה.
השיפור הזה התאפשר רק כי הפרוייקט הספציפי הזה לא צריך לתמוך בPHP4.

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

אז איך מתקדם האימוץ של PHP5?
החל מFireStats 1.3 ששחרתי לפני יותר משנה, FireStats מכילה רכיב ששולח (באישור המשתמש) מידע מערכת אנונימי. חלק מהמידע הוא גרסאות הPHP והMySQL.
הכוונה היא שאני אוכל להשתמש במידע הזה כדי להחליט בצורה יותר מושכלת במה אני צריך לתמוך.
המידע הצטבר לי בבסיס הנתונים, ונכון לכרגע יש לי מידע על כמעט 12000 התקנות. מה שאומר כמעט 12000 שרתים בעולים (אני מתעלם ממקרים של כמה התקנות על אותו שרת).
למי שתוהה, זה לא אומר שFireStats הותקנה 12000 פעמים, אלא ש12000 פעמים המתקינים הסכימו לשלוח מידע מערכת אנונימי.
מי שרוצה את המידע הגולמי מוזמן לקחת אותם מפה (יצוא MSQL, כ5 מגה דחוסים, 65 מגה פרושים).

אז ישבתי כמה שעות כדי להוציא מהנתונים הגולמיים שני גרפים נחמדים:
הראשון הוא אחוזי ההתקנות של PHP 4 מול PHP 5, במהלך השנה האחרונה.
למרות שאחוזי ההתקנה של PHP4 ירדו במהלך השנה האחרונה מ52% ל38%, עדיין מי אי אפשר להתעלם ממנו. נקווה שהוא ימות סופית בקרוב:
installed php versions
השני הוא אחוזי ההתקנות של הגרסאות המשמעותיות של MYSQL:

כיף לראות שMYSQL 5.0 שולט בשוק, אבל נראה שMYSQL 4.0 הזוועתי נתקע על 7% ולא רוצה למות.
בכל מקרה, MYSQL 4.0 הוא בהחלט מועמד לנטישה, וכבר היום יש לא מעט תכונות חשובות של FireStats שלא נתמכות בגרסא הזו.
installed mysql versions

פורסם ב

openid ושאר ירקות

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

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

יש כל מני שרתי openid, מסובכים יותר או פחות.
אחד הפשוטים שבהם הוא phpMyID, שמממש פחות או יותר בדיוק את מה שאני צריך:
שרת openid למשתמש בודד (אפשר כמה משתמשים אם רוצים, וזה אפילו קל).
ההגדרה שלו כוללת עריכת קובץ PHP, הוספה של שם משתמש וגיבוב md5 של הסיסמא ועוד כמה דברים, וזהו.
יותר קשה ממה שזה נשמע, ככה נראות השורות שצריך לערוך:
[code]
'auth_username' => 'test',
'auth_password' => 'e8358914a32e1ce3c62836db4babaa01'
[/code]

הקישקוש בסיסמא הוא גיבוב md5 של username:phpMyID:password, יש הרבה דרכים לחשב אותו, למשל:
[code]
echo -n 'username:phpMyID:password' | openssl md5
echo -n 'username:phpMyID:password' | md5sum
[/code]

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

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

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

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

פורסם ב

FireStats 1.5.0-beta

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

  • שיפור משמעותי בביצועים של קליטת כניסות
  • תמיכה בIPV6
  • סינון לפי טווח כתובות IP ולפי כתובת URL או מפנה
  • שיפורים בתצוגת המפנים האחרונים
  • שיפורים בתמיכה במנועי חיפוש

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

    פורסם ב

    ייעול הכנסת נתונים מנורמלים לבסיס הנתונים בFireStats

    במסגרת מקצה אופטימיזציות ל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 דקות, ואולי אפילו בכל פעם שמנהל האתר בודק את הסטטיסטיקות.
    מימוש כזה יגרום לעסק להיות שקוף, תוך הורדה משמעותית מהעומס על השרת.

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

    פורסם ב

    וורדפרס וmod_cache

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

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

    פורסם ב

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

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


    #ip_address host1,host2,...,hostn
    #example:
    1.2.3.4 firefang.net

    מה שצריך לעשות זה להוסיף שורה שמתחילה בכתובת ה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 נחשב כבר מספיק יציב, ופתחתי את הברז של ההתראה על גרסא חדשה, מה שאומר שצפוי גשם של מורידים בימים הקרובים, לא לשכוח מטריות.