הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
על המחלה הכרונית של אנשי הקוד הפתוח
לכל האנשים שמתעסקים בקוד בפתוח במלואו מובן המילה יש מחלה כרונית מדבקת קשה: לנסות לתקן כל דבר. זהירות, זו מחלה מדבקת ומאוד קשה. היא גורמת בסופו של דבר לפגיעה במקצועיות, מכיוון שמפתחי תכנה־חופשית לא יותר יהיו מסוגלים לעבוד עם ספריות קוד סגור, כי הם לא יוכלו לדבג בעיות שונות עם קבצים בינאריים בלבד!
כדי להוכיח את הטענה, אני אביא את רשימת הטלאים שיצא לי לשלוח לפרויקטים שונים.
- וורדפרס־בעברית שני טלאים: בעיית מרכאות ותיקוני עיצוב -- שניהם נכנסו. (טלאי נוצר כתוצאה משימוש במערכת).
- ספריית FastCGI בעיה באופן עבודה א־סינכרוני -- לא נכנס, החבר'ה שם לא מי יודע מה חביבים. (טלאי כתוצאה משימוש בספריה)
- ספריית SOCI תמיכה בטעינה דינמית של מודולים -- נכנס.
הטלאי נכתב בתקווה להשתמש בספריה בעתיד. לצערי, בסוף הייתי צריך לוותר עליה בגלל בעיות רבות אחרות. - ספריית FriBiDi תיקון באג בהמרת קידוד -- נכנס. (התגלה בעבודה על biditex).
- svnkit -- מספר טלאי לתמיכה ב־OpenVMS -- נכנסו. למעשה בלעדיהם אי אפשר היה לעבוד עם svn ב־VMS בכלל.
- טלאי ל־lighttpd שמתקן באג המונעה העלאת תהליכי scgi ע"י השרת -- נכנס. (הטלאי הוא תוצאת הפיתוח של CppCMS)
- בקרוב, כנראה, אצטרך להכין מספר טלאים ל־asio ו־boost כדי להבטיח תמיכה טובה יותר ב־OpenVMS (זה עובד אבל מקרטע פה ושם).
בטח יש עוד כמה טלאים שפספסתי... אני כבר לא זוכר מה כתבתי ומתי.
מה המסקנה שלי מכל הסיפור הזה? אני כבר לא מסוגל לעבוד עם ספריות קוד סגור כי אני לא סומך עליהן, כי אני לא אדע מה לעשות אם תהיה בעיה, לא אדע לדבג אותה!
רבותי, אל תשתמשו בקוד פתוח -- זה מדבק ופוגע בעתידכם המקצועי!
על FastCGI, על SCGI ועל בחירה של RoR ו־Django.
לאחרונה הפרוטוקול Simple CGI הופך ליותר ויותר פופולרי והופך לבחירה טבעית או אפילו ברירת מחדל של תשתיות פיתוח לאינטרנט החדשות כמו Django ו־RoR. במה מדובר? מדובר בפרוטוקול מאוד פשוט שדומה באופי שלו ל־FastCGI אבל הספציפיקציה שלו מורכבת מכמה עשרות שורות, כך גם המימוש דורש מעט קוד (רוב המימושים שראיתי לא הכילו יותר מ־100--200 שורות קוד).
למעשה הפרוטוקול הזה הוא תחליף אידיאלי ל־FastCGI עבור:
- שרתי אינטרנט קטנים שרוצים לחבר יישומים גנריים בקלות רבה, בגלל פשטות המימוש.
- יישומי אינטרנט שהמימוש של הפרוטוקול דורשת כמה עשרות עד מאה שורות קוד. בניגוד ל־FastCGI שהמימוש המלא שלו מאוד מורכב.
- אפשרות לכתוב רכיב תקשורת עם שרת אינטרנט בצורה מהירה ללא ספריה צד ג'. למעשה, בניגוד ל־FastCGI, אפילו לא קיימת ספריה סטנדרטית עבור המשימה.
- הפרוטוקל לא פחות חזק מ־FastCGI בכל הקשור לביצועים.
נראה לעין שאין שום סיבה לא להשתמש בפרוטוקל הזה על פני FastCGI, אבל במציאות יש הבדל גדול מאוד. אחרי מבט בספציפיקציה של FastCGI נתחיל:
המשך...שוחררה גרסת בטא הראשונה של CppCMS.
אחרי כחצי שנה של פיתוח שוחררה גרסת בטא הראשונה של CppCMS תחת רישיון LGPL v2.1.
מה זה CppCMS?
זאת תשתית לפיתוח יישומי Web ב־C++ המספקת ביצועים יוצאים מן הכלל שלא ניתן להשיג בשימוש בטכנולגויות מקובלות.
מה המרכיבים של CppCMS?
הגרסת בטא כוללת:
- תשתית לכתיבת יישום web ב־C++: cppcms.
- ספרית תבניות tmpl המאפשרת הפרדה נוחה בין הקוד לבין תוכן HTML.
- ספרית גישה לבסיסי נתונים שונים dbixx -- למעשה מעטפת C++ נוחה עבור libdbi.
- רשימת דוגמאות, בהן "מיני־פורום" המדגים את העבודה עם התשתית.
מה ייתווסף לגרסה יציבה ראשונה שלא קיים בבטא?
הרבה תיעוד שעדיין לא נכתב.
זה נורא מעניין איך אני מתחיל?
- להורדת CppCMS מ־SourceForge.
- כותבים "שלום עולם" בעזרת CppCMS.
- כותבים "שלום עולם" עם שימוש בתבניות בעזרת CppCMS.
- כותבים "מיקרו־פורום" בעזרת CppCMS.
רוצים עוד?
יש מידע רחב בנושא בבלוג הפיתוח של CppCMS. כמו כן, תמיד אפשר ללמוד מקוד קיים, למשל, הקוד של הבלוג הזה הזמין דרך svn.
דו"ח התקדמות CppCMS והשאלת שם הפרויקט.
שם חדש לפרויקט
לאחרונה אני מתחיל להבין ששם הפרויקט הוא מאוד לא מוצלח. רבים חושבים שמדובר ב־Content Managment System כמו Drupal ולא ב־Web Developmen Framefork כמו Django ואחרים.
לכן אני מתלבט: האם לשנות את שם הפרויקט ואם כן היא איזה שם לבחור?
דו"ח התקדמות
לאחרונה הוכנסו שינויים גדולים ועקרוניים שהופכים את ה־framework להרבה יותר גמיש וניתן להרחבה בקלות יחסית.
שינויי API הפנימי השונים
- API של שרת אינטרנט הופרד למודולים נפרדים. כיום CppCMS תומך ב: cgi, fastcgi ו־scgi . שינוי הממשק נעשה ע"י שינוי קטן בקובץ הגדרות הרצה.
- הופרד API של cache כך שכל מודול נטען בנפרד. כיום יש תמיכה בשלושה סוגי ה־cache: thread share, dummy ו־fork שעליו אספר בהמשך.
- הפרדה של מודי העבודה השונים: mod-thread-pool, single-worker-thread ומוד חדש ומבטיח mod-prefork.
הוספת mod-prefork
השינויים הגדולים האחרונים הם בעיקר לצורך התמיכה במוד עבודה בטוח -- prefork כאשר כל פעילות מופרדת לתהליכים נפרדים המפוקחים ע"י תהליך האב, כך שנפילה של תהליך, או זליגת זיכרון לא תגרום לבעיה בכל היישום. כמו כן, התווסף מוד עבודה של cache חדש: מוד בו כל הנתונים נמצאים בזכרון משותף.
למעשה mod-prefork אמור להפוך לברירת מחדל בגלל שהוא הרבה יותר בטוח וסלחני לטעויות המפתחים שאמור למנוע השבתה של מערכת במקרה של באג.
הסיפור המעניין בפיתוח של המוד הוא למעשה המימוש של cache. המימוש התבסס על קוד ה־cache הקיים שמבוסס על STL, רק... שיניתי allocators כך שהקצאת זכרון תתבצע מקטע זכרון משותף המנוהל ע"י libmm. למעשה, העובדה שכל התהליכים הם "כפילים" של אותו האב המשתפים את כל הכתובות, מאפשרת לדחוף לזכרון משותף כל מחלקה שהיא ואפילו ייצורים מוזרים כמו STL. הדבר אינו אפשרי במערכות הפעלה שלא תומכות ב־fork.
מוד העבודה הזה יודע ליצור תהליך חדש בצורה אוטומטית אם אחד התהליכי העבודה נפל, ובנוסף מאפשר להגביר את מספר האיטרציות שכל אחד מתהליכי העבודה מבצע עד להחלפתו בתהליך רענן. זה מאפשר לא לדאוג לזליגות זכרון בכלל, אם כי במחיר קטן של ביצועים הנדרשים ליצירת תהליך חדש פעם בה כמה זמן.
מאמר מקביל בבלוג פיתוח (אנגלית)
Autotools - קשה איתם, אבל אי אפשר בלעדיהם.
אחד הכלים השנואים ביותר ע"י המפתחים בעולם Unix זה autotools. מצד שני, זה גם הכלי הנוח ביותר עבור משתמשים שהתקנת תוכנה כלשהי מסתכמת בהרצת שלוש בפקודות
./configure
make
make install
במה מדובר? מדובר בכלי שמאפשר: בנייה, הפצה, בדיקה, התקנה, הסרה, קונפיגורציה של תכנה, ספריות, תיעוד בפלטרפורמות מרובות בצורה אוטומטית. נשמע מפוצץ? וזה אכן הדבר. נכון להיום זה אחד הכלים החזקים שקיימים בתחום *nix.
אבל, אם זה כלי כל־כך חזק, למה כל־כך רבים שונאים אותו?
המשך...