ארכיון חודשי: יוני 2008

אסטריסק 1.2 מול 1.4

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

החודש התקנתי שרת חמישי ללקוח שלי עם אותה מערכת, רק הפעם הלכתי על גרסה 1.4. כל תת גרסה של Asterisk (כלומר 0, 2, 4 ו6) מכילים שינויים מאוד גדולים לכל דבר. מהמבנה של ה cli בהם רשימת הפקודות משנה את המיקום שלה (דווקא הדרך הזו נראת יותר טוב ממה שזה נשמע, הם מאחדים חוקים של איך למצוא פקודות, במקום שכל מודול יספק מסלול שונה לפקודות), דרך ה Manager וכמובן ה Dailplan.

הבעיה התחילה כאשר ניסיתי להשתמש ב Dailplan של מערכת ה Click2Call שכתבתי עם גרסת 1.4. איך שניסיתי להוציא שיחה, הוא הגיע לי מייד ל DeadAGI בלי להגיע בכלל לDail. בהתחלה לא הבנתי מה קרה, ניסיתי לקרוא לוגים שונים, קראתי את המסך של אסטריסק. ועל פניו שום דבר לא נראה בעייתי.

ואז התחלתי לשים לב לDumpChan ול NoOp שהכנסתי במקור ל Dailplan בעקבות בעיות שהיו לי עם PRI של חברת HOT. אחת מהתוספות שהכנסתי ל NoOp היתה TIMESTAMP על כל פעולה שאני עושה בDailplan, ובעצם ראיתי שהTIMESTAMP לא חוזר. אז עכשיו הלכתי להסתכל על התיעוד של המשתנים, והסתבר שהמשתנה {TIMESTAMP}$ מוגדר כ deprecated. עכשיו התחלתי לבדוק עוד כמה פקודות, שראיתי כי הן לא מתבצעות, וגיליתי פקודה שב1.4 כבר לא בשימוש, למרות שב 1.2 היא לא סומנה כ Deprecated כאשר עבדתי על ה dailplan.
אחרי שבדקתי את כל הפקודות בהם אני משתמש, הצלחתי לגרום לתוכנית שלי לחזור ולעבוד, 30 דקות אחרי שהתחלתי את הנושא.

זה התחיל בvideo cast

אתמול ניסיתי לצלם video podcast (מילה בעברית ?) שידריך איך לעבוד עם לזרוס, כאשר ה cast הראשון מסביר איך להתקין רכיבים בלזרוס.

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

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

כשהרצתי את לזרוס, הכל עבד כמו שצריך הבעיה התחילה התקנת רכיב, בו לזרוס מאתחל את עצמו מחדש ואז לזרוס ברח לי מהDISPLAY של Xnest ויצא ל DISPLAY הראשי שלי.

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

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

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

סך הכל עבר עלי סופ"ש מאוד פורה

האיחוד החם

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

את התהיות שלי העברתי בזמנו לפוסט.

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

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

פתאום הכל ברור !

פיצ'רים מדהימים בלזרוס 0.9.26

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

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

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

בכל מקרה, 0.9.26 הולכת להיות גרסה מאוד מעניינת. הדבר הכי חשוב מבחינת כולנו בגרסה הזו, היא בראש ובראשונה תמיכה מלאה ב UTF-8 בכל widget התומך בה. יש אפשרות גם לקבוע מה הcharset של הקובץ מתוך העורך טקסט, והתחילו להיכתב בוויקי הוראות כיצד להתנהג עם UTF-8 וכיצד להמיר טקסט.

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

יש למה לחכות בשביל גרסת 0.9.26, ומי ידע, אולי גרסה 1 תהיה שונה לגמרי ממה שחושבים שהיא תהיה כרגע.

נימרוד

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

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

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

ימי הביניים של הטכנולוגיה

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

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

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

המדחנים בנתניה

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

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

עכשיו אני מבין למה יש כל כך הרבה סניפי דואר בנתניה, בשביל לשלם קנסות על חניה…

סתם מקרה מעצבן.

צעדים לניפוי שגיאות

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

ב FPC מגיעים 2 כלים נוספים ל writeln אשר יעזרו לנו למצוא בעיות בתוכנה שלנו הרבה לפני שניגש לתותחים הכבדים של gdb ו valgrind:

להמשיך לקרוא

שבועיים וקצת עם מנדריבה

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

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

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

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

אין ספק לא עושה

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

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

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

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

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

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

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

קצת חומר למחשבה…