הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מחשבות: פרויקטים גדולים, גם אם יתרסקו ישארו משהו אחריהם...
לא מזמן יצא לי לקרוא על olpc -- בעיקר דעות שונות: האם זה רע? האם זה סוף או אולי הסוף היה כבר בהתחלה?
מה שגרם לי לחשוב אופן כללי על פרויקטים עם "אגו" גדול ותהיות לגבי עתידו של CppCMS שגם לו יש "אגו גדול", אם כי בממדים הרבה יותר קטנים. יש לא מעט המצאות ורעיונות גדולים שמתרסקים בשלב היישום, אולי הטכנולגיה עדיין לא בשלה, העיתוי לא מתאים, סתם השיווק כושל או בעיות אחרות. מה שברור שפרויקטים "עם אגו גדול", גם אם נכשלים, יכולים להוריש טכנולוגיות או רעיונות שימצאו שימוש במקומות אחרים.
לאחרונה, אני תוהה, מדוע אני משקיע כל־כך הרבה מאמץ יושב עד 1:00 בלילה, כותב תיעוד, מדבג עבור פרויקט שאני יודע שאולי שתיים וחצי אנשים ישתמשו בו?
כשהעולם דווקא מתקדם בצעדי ענק לכיוון BloatWare, או לכיוון של פיתוח מאוד מהיר בשפות קלות כי מחירי החומרה יורדים, אני עומד כנגד ואומר: "אתם טועים". הרי גם אם אני צודק, הסיכוי שאשכנע מישהו הוא זניח... מה הסיכוי שהטכנולוגיה שנשמעת כמשוגעת, מזוכיסטית תשמש מישהו ועוד יותר מה הסיכוי שייצא לי מזה משהו (למעט למידה).
אחרי מחשבה שנייה, אני מתחיל להבין... גם אם זה לא יצליח, יש רכיבים שיכולים לשרוד. גם אם OLPC ייכשל, יישאר Sugar עם רעיונותיו המהפכניים (שאולי אפילו אני לא מעכל). כך גם אם הפרויקט שלי ייכשל, כי לא יהיה לו שום ביקוש בשוק, אני כבר רואה מספר דברים שיישארו אחריו:
- מערכת תבניות שאפשר להשתמש בה בהמון מקומות בלי קשר ל־HTML
- מעטפת C++ עבור libdbi שאני בטוח שיימצא לה שימוש.
- מערכת cache גמישה ומתוחכמת שהתכנון שלה נמצא כרגע בעיצומו, תוכל לשמש כל פרויקט webי שלאו דווקא כתוב ב־C++.
כך שאני מקווה שלא בזבזתי שעות שינה לשווא. למען האמת, למדתי מכל הפרויקט הזה כל־כך הרבה, שאין צורך להצטער.
התנצלות: אני ידוע שזו חוצפה להשוות CppCMS עם OLPC, אבל בכל זאת, צריך להיות טיפה חוצפן ;)
לבנות את CppCMS.
בזמן האחרון, התחלתי לקבל שאלות "כיצד לבנות את CppCMS" או "האם יש לך חבילות עבורה". לכן, פרסמתי הוראות בניה" של המערכת.
(אגב, מישהו יודע תרגום נכון של מילה framework לעברית?)
כך שכל מי שרוצה להתנסות, יכול במאמץ סביר לבנות את המערכת ולהסתכל עליה. חייב לציין, שהמערכת עדיין בשלבי בנייה מוקדמים כך ששום דבר לא יציב, וייתכן ויהיו רגעים בהם לא תצליחו לבנות אותה בכלל.
למרות שרשימת התלויות שהצגתי נראית מפחידה, למעשה, לא תהיה שום בעיה לבנות אותה על Debian Lenny או Ubuntu Hardy. למעשה, אני אפילו הצלחתי לבנות אותה על cygwin, אם כי הייתי צריך לקמפל כמה ספריות צד ג'.
כל מי שרוצה לנסות, מוזמן. אני אשמח לקבל תגובות.
לחיות עם גרסה יציבה של דביאן
מי שמכיר אותי יודע, שאני שונא לתחזק מחשבים, להתעסק בהם ואוהב שהם פשוט יעבדו (לצערי זה לא תמיד קורה). לכן, אני בחרתי בדביאן יציבה בתור מערכת ההפעלה הראשית שלי שאני עובד איתה גם על מחשב נייד ונייח. פשוט, זה מונע ממני כל צורך לשדרג מערכת יותר מידי, לדאוג מכן שהדברים עלולים להישבר ברגע לא מתאים ועוד.
הבעיה היא, שלפעמים אני צריך תכנה ספציפית בגרסה עדכנית שלה. מה עושים?
המשך...מימוש thread safe של gettext.
אחת המגבלות החשובות של gettext היא יכולת העבודה עם יותר משפה אחת בתוך אותו יישום או ליתר דיוק, אפשרות עבודה עם שני תרגומים שונים מ־Threadים שונים.
כתבתי מימוש משלי של פונקציוליות של GNU Gettext שתואם לו, יודע לעבוד עם קבצי תרגום שלו ומאפשר בחירה שקופה של מנוע gnu gettext או מנוע חלופי שהוא thread safe.
ראה פירוט כאן.
לא כל העולם כותב באנגלית
רוב מערכות התוכן ופילטרים חכמים כוללים רכיבים שהופכים את המירכאות
ברוסית וצפרתית, למשל,משתמשים במירכאות «כאלה», בגרמנית משתמשים בזוג „כזה“ ובעברית משתמשים בזוג "רגיל". כך שהמנגנון החכם שהופך את המירכאות לזוג שיש באנגלית הוא פשוט לא נכון, כמעט בכל מקרה, חוץ מכתיבה באנגלית.
אבל המצב די מעצבן, אם אני למשל, רוצה לוקחת תוסף SmartyPants כתוספת ל-Markdown שהופך שלוש נקודות ל-"…" ושני מינוסים לקו-מפריד "---", אז אתה מקבל גם מירכאות, כנ"ל גם מפתחי WordPress סירבו לאפשר הפעלה או ביטול של מירכאות חכמות לפי הדרישה (התיקון יש רק בגרסה עברית של רן). כמובן שיצא לי להיתקל בבעיה הזו בעוד הרבה מקומות, שברוב המקרים אם אתה רוצה לשנות את ההתנהגות אתה צריך לכתוב טלאים.
בקיצור, אם אתם מכירים מערכות תוכן, פילטרים או רכיבים אחרים שמשתמשים במירכאות חכמות כברירת מחדל, תציקו למפתחים שלהם, אולי הם יפעילו אותם כאופציה והאינטרנט ייראה קצת יותר טוב, גם כשלא מדובר באנגלית.
