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

מערכת גדולה

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

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

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

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

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

התמקצעות טכנולוגית

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

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

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

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

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

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

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

עוד חומר למחשבה

Ruby שונה שפה

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

הבעיה הראשונה שהיתה לי היא לבחור בטכנולוגיה המתאימה לפרוייקט. בעבר כתבתי לאותו לקוח כלים שכתובים ב PHP ובג'אווה (כאשר אותו לקוח מעדיף את ג'אווה על פני כל טכנולוגיה אחרת).

האפליקציה מקבלת מידע ב XML-RPC, ובגלל שיש לי ספרייה ממש נחמדה ב PHP אשר משתמשת בה, החלטתי להישאר איתה, וקליטת המידע מתבצעת בPHP.

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

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

בשביל לכתוב שדון (daemon) ברובי, כל מה שאני צריך זה 3 שורות קוד, כאשר 2 מהן עושות import, ועוד שורה שלמה של להגיד למחלקה בשם Daemons להריץ קובץ שנמצא תחת do loop. ממש ממש פשוט.

ובנוסף היו לי ספריות לAsterisk Manager Interface וכמובן ל Asterisk Gateway Interface, מה שאומר שאני לא צריך להתעסק בשטויות (כמו להגדיר daemon בפרל, PHP, C ופיתון, או יצירת התממשקות של AMI בפסקל).

מה שנשאר לי לעשות זה Copy Paste (לאחר בדיקה וניסויים) ל ThreadPool שנבנה בשביל רובי ע"י אנשים נחמדים וזהו ! אני יכול להתעמק רק בקוד שאני חייב לכתוב.

התוצאה היא 300 שורות קוד (כולל copy paste של ה ThreadPool, הערות, רווחים וכו') ב3 קבצים, כאשר קובץ אחד הוא השדון שלנו, הקובץ השני הוא קוד שמדבר עם AMI, והקוד השלישי הוא בעצם משמש בתור AGI.

לפעמים הגמישות בטכנולוגיה משתלמת.