ערכה חדשה – מנדיגו

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

תודה לאח"י דקר על העזרה בתיקון תחלואי העברית ולטום שהסכים להשקיע זמן בתמיכה בעמי המזרח התיכון.

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

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

פיתוח PHP עם PDT

היסטורית, מפתחי PHP תמיד היו מקופחים.
בזמן שמפתחים לשפות אחרות נהנו מסביבות פיתוח מתקדמות, עם יכולות דיבאג (נקודות עצירה, בדיקת ערכי משתנים בזמן ריצה ועוד), השלמת קוד תלויית הקשר ועוד, הרוב המכריע של מפתחי הPHP השתמשו בעורכי טקסט פשוטים יחסית (ואני לא מזלזל בVIM ובEmacs).
את FireStats התחלתי לפתח כאשר לא ידעתי כמעט כלום על PHP, ובוודאי שלא ידעתי על סביבות הפיתוח המומלצות לפיתוח בPHP, כך שהתחלתי את הפיתוח בשימוש בVIM ישירות על שרת הפיתוח שלי (המחשב בסלון), והייתי מרוצה מהתוצאות.
לפני מספר חודשים נתקלתי בMylar, שאיפשר לי התממשקות נוחה למערכת ניהול הבאגים של FireStats, שעובדת על trac.
החלטתי שזה שווה את המאמץ של המעבר, והתחלתי לחפש פתרון PHP לEclipse.
בהתחלה מצאתי את PHPEclipse, פלאגין שעובד די טוב, אבל כמה באגים עיצבנו אותי, ושמתי לב שהפרוייקט די רדום, אז נטשתי אותו לטובת PDT שמפותח כתוסף רשמי של פלטפורמת Eclipse, בעיקר על ידי מפתחים של Zend.

PDT נמצא כרגע במצב די טוב, יש כמה באגים קטנים אבל הפרוייקט חי ומשחרר גרסאות חדשות כל כמה חדשים.
ההשלמה האוטומטית עובדת יפה מאוד, גם בהקשר של PHP, גם בהקשר של HTML ואפילו בהקשר של CSS וJavaScript.
בנוסף, במאמץ קטן יחסית ניתן לאפשר דיבוג באמצעות xdebug מתוך Eclipse (!), ממש סוף הדרך.

עבודה עם PDT:
pdt.png

דיבאג עם PDT:
pdt1.png

בונוס למגיב הראשון שיספר מה עושה הפונקציה fs_sum_search_tree.

הפיד שבער

כמו שהבטחתי, הפסקתי להשתמש בFeedburner, מה שאומר שכל מי שמנוי על הרסס צריך לוודא שהוא מנוי על הפיד הנכון, שהוא:
http://firefang.net/blog/feed/

ולא על הרסס של Feedburner.

Tivo וGPL3

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

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

גוגל קונים את פידברנר

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

פענוח שפות פורמליות

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

key1=value1
key2=value2
key3=another value

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


private static void parse(BufferedReader reader) throws IOException
{
String line = null;
while ((line = reader.readLine()) != null)
{
StringTokenizer tok = new StringTokenizer(line, "=");
String key = tok.nextToken();
String value = tok.nextToken();
System.err.println("Read: key = " + key + ", value = " + value);
}
}

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

key1=ABC\
DEFG

פה יש רק ערך אחד לפי החוקים של השפה.

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

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

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

בגדול, יש חלוקה כזו:
חלק ראשון הוא המנתח הלקסיקלי, שמקבל זרם תווים, ומוציא זרם של לקסמות, הידועים גם כאסימונים (Tokens). האסימונים מוגדרים באמצעות ביטויים רגולריים (שפה דומה לשפה שמשמשת את grep).
חלק שני הוא המנתח התחבירי, שמקבל זרם של אסימונים מהמנתח הלקסיקלי, ומוציא עץ תחביר אבסטרקטי (Abstract syntax tree).
יש כלים שיודעים לקבל הגדות לקסיקליות ותחבירות, ולייצר מזה בצורה אוטומטית קוד שיודע לפענח קלט בשםה הנתונה. למעשה, הטכניקה המקובלת לכתיבת קומפיילרים כבר עשרות שנים מתבססת על כלים אוטומטיים כאלו.
את הPreprocessor של אנטנה כתבתי תוך שימוש בantlr, שהוא כלי כזה שכתוב בג'אווה, אבל יודע לייצר קוד במגוון שפות, ובקורס קומפילציה שאני לוקח כרגע בפתוחה לומדים להשתמש בכלים הקלאסיים – flex וbison.
לדעתי antlr הרבה יותר סימפטי לעבודה.

אם תהיה דרישה אני ארחיב עוד בנושא.

טריקל

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

ככה זה נראה בלי טריקל:

$ wget http://yadan.net/bulk.dat
–22:01:39– http://yadan.net/bulk.dat
=> `bulk.dat'
Resolving yadan.net… 10.0.0.2
Connecting to yadan.net|10.0.0.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 20,480,000 (20M) [chemical/x-mopac-input]
14% [=============> ] 6,966,584 11.07M/s

וככה עם:

$ trickle -d 50k wget http://yadan.net/bulk.dat
trickle: Could not reach trickled, working independently: No such file or directory
–22:04:33– http://yadan.net/bulk.dat
=> `bulk.dat.2'
Resolving yadan.net… 10.0.0.2
Connecting to yadan.net|10.0.0.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 20,480,000 (20M) [chemical/x-mopac-input]

1% [> ] 278,528 52.48K/s ETA 06:15

בעיות רשת מוזרות

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

בעיית רשת מוזרה מספר 1:

BattleField 2142, משחק רשת מרובה משתתפים עובד היטב, עד שיום בהיר אחד הוא מפסיק לראות שרתים ברשת.
פניתי לתמיכה של EA, שהציעו להסיר ולהתקין מחדש, תוך מחיקה של כל רמז לספריות נוספות שהמשחק שומר (במילים אחרון, אין להם מושג והם יורים באפלה).
עקבתי אחרי ההוראות, וכמובן שהבעיה לא נפתרה.
בצר לי, הורדתי את WireShark (לשעבר Ethereal), שהוא Network sniffer רב עוצמה, והפעלתי אותו לפני ההפעלה של המשחק.
wireshark
די בקלות זיהיתי את הבעיה: המשחק שולח בקשת DNS למציאת כתובת הIP של השרת שמחזיק את רשימת השרתים, מקבל שגיאה מהDNS ומתעלם ממנה ומפסיק לנסות בלי למסור הודעת שגיאה למשתמש.
ברגע שהחלפתי את שרת הDNS שלי הבעיה נפתרה.

בעית רשת מוזרה מספר 2:

Call of duty 2, עוד משחק רשת משובח, עובד היטב ברשת המשרדית, עד שיום בהיר אחד הוא מפסיק לראות שרתים אחרים.
במילים אחרות, עמרי לא יכול להצטרף לשרתי המשחק ברשת, ונאלץ לעבוד בעבודה.
לאחר הטחת האשמות סרק ברשת, בסוויץ' במערכת הפעלה ובאלוהים, הפעלתי את WireShark על שני מחשבים, אחד בו אין בעיה, וזה שלי.
לאחר שהפעלתי את המשחק בשניהם, בחנתי את תעבורת הרשת, וגיליתי את הדבר הבא:
המשחק שולח בBroadcast פקטת UDP לכל הרשת כשהוא מחפש שרתים, והשרתים אמורים לענות לו ולמסור לו מידע על עצמם. (כדי לשלוח Broadcast צריך לשלוח את הפקטה לכתובת 255.255.255.255).
עד פה הכל טוב, רק שראיתי משהו מוזר במחשב שלי. במקום לצאת מכתובת הIP הרגילה שלי הוא יצא מכתובת IP אחרת, שבכלל לא נראית כאילו היא ברשת הפנימית שלנו.
מסתבר שהכתובת הנ"ל (192.168.40.1) שייכת למתאם רשת וירטואלי של VMWare, ומסיבה עלומה המשחק שלח את חבילת הUDP כאשר הכתובת של המתאם היא כתובת המקור של החבילה. השרת ניסה לענות, אבל מכיוון שהכתובת לא ברשת לא קיבלתי את התשובה.
אחרי ביטול של מתאמי הרשת של VMWare הבעיה נפתרה.

בעיית רשת מוזרה מספר 3:

תוכנה שאנחנו מפתחים בעבודה מקבלת זרם של חבילות UDP משרת.
התוכנה עובדת טוב מול שרת אחד, ומאוד לאט מול שרת שני, שני השרתים מריצים את אותה תוכנה בדיוק.
הפעלה של WireShark על השרת והמכונה שמריצה את הלקוח מראה שהשרת שולח את החבילות בקצב הנכון, והחבילות מגיעות למכונת היעד באותו קצב, ובכל זאת לאפליקציית הלקוח החבילות מגיעות מאוד לאט.
הלקוח רץ על WTK, שהוא אמולטור של סביבות ג'אווה של פלאפונים. לWTK יש כלי Profiling פנימי, שמאפשר להגיד איפה האפליקציה משחיתה את זמנה.
הפעלתי את הפרופיילר, והסתבר שהיא משחיתה את מיטב זמנה בפונקציית מערכת בשם getHostByName.
תפקידה של הפונקציה הזו הוא בעצם לקבל כתובת שמית ולהמיר אותה לכתובת IP מספרית, במילים אחרות – לקרוא לDNS.
מסיבה לא ברורה הפונקציה לקחה הרבה זמן, ומסיבה לא ברורה היא נקראה עבוד כל חבילת UDP שהגיעה לאמולטור (באג באמולטור לדעתי, אבל שיהיה).
לחלונות יש קובץ בשם hosts בספריית החלונות, שדומה מאוד לאותו קובץ במערכות יוניקס (זה מראה על הקשר בין חלונות ליוניקסים), הקובץ משמש להוספה ידנית של רשומות לDNS המקומי.
ברגע שהוספתי את כתובת הIP של השרת לקובץ ההוסטים הבעיה נפתרה.

עד כאן פינתנו, בעיות רשת מוזרות.