הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
כשאתה לא החלק מהסלסה אלא סלסה היא חלק ממך
לפני מספר שבועות, בשיחה על קונגרס הסלסה, אדית (אשתי) אמרה לי: "אנחנו לא חלק מסלסה, אלא סלסה היא חלק ממנו". בהתחלה לא ירדתי לסוף דעתה, לקח לי הרבה זמן לעכל ולהפנים את המשפט ויותר חשוב מזה, להבין עד כמה הוא נכון!
כל רקדן סלסה עובר מספר שלבים:
- שלב התעניינות: אתה הולך למועדון אחד, לוקח שיעורים, לאט־לאט משתפר.
- שלב התמכרות והכחשה: אתה הולך לפחות פעם--פעמיים בשבוע לסלסה, אתה מכיר את רוב המועדונים המרכזיים והקהל שלהם באזור המגורים שלך. סלסה הופכת לתחביב העיקרי שלך.
- שלב התמכרות קשה: אתה הולך לפחות לאחת הסדנאות שכל סלסרו "חייב" להגיע אליהן: "מיומנות הובלה", "מוזיקה וקצב", "לידי־סטייל", "קורס מדריכי סלסה". אתה מבלה לפחות פעמיים בשבוע במועדון סלסה ולפחות פעם אחת בשבוע נשאר בו עד 2--3 בלילה. לפעמים אתה חוזר הביתה בבוקר. בעבודה כבר כולם התרגלו, שיש ימי השבוע שבבוקר "אין עם מי לדבר".
ניתן למצוא את השלבים האלה בהרבה כתבות באתרי סלסה שונים. מה שכן, רוב הכתבות האלה מתעלמות מהשלב האחרון... כי בד"כ הוא הרבה פחות מעניין:
יש כאלה נמאס להם, זה עבר להם והם מסתכלים לאחור בלא געגוע; יש כאלה שהופכים את זה למקצוע שלהם; ויש כאלה שהם יוצאים מסצנת הסלסה: אתה לא תראה אותם במועדון בכל יום רביעי, אתה לא תראה אותם כותבים בפורומים, אתה לא תרים אליהם טלפון להגיד: "היי, מחר יש הופעה במועדון ב', אתם באים?"; אבל... עדיין, כשיש זמן והזדמנות נוחה הם יוצאים למועדון זה או אחר לרקוד שעה--שעתיים, כשמתכננים חופשה מסודרת מסתכלים על פסטיבל סלסה קרוב כדי לשלב חופשה עם אחד מהתחביבים שלהם, "מכרי־הסלסה שלהם" שנמצאים בשלב 3, רואים אותם כ"נוטשים" ובכלל, לא רואים אותם הרבה.
הם כבר לא חלק מסצנת הסלסה, אבל עולם הסלסה הוא חלק בלתי נפרד מהם. זהו אולי השלב האחרון והחשוב ביותר של כל סלסרו... כי סלסה, לא יכולה להיות חלק מרכזי בחיים שלהם, אלא אם אתה הופך אותה למקצוע. אבל, היא כן יכולה להיות חלק חשוב בחיים, יחד עם הרבה דברים חשובים אחרים.
למעשה, השלב הזה הוא השלב החשוב ביותר בהתפתחות של סלסרו --- כי הוא מראה: "האם באמת סלסה וריקוד חשובים להם". רק, בניגוד לשלבים הקודמים, זה קורה בפרופורציות סבירות בהתאם לאילוצים של חיי יום־יום שכל אחד צריך לחיות אותם.
האם אתה מוכן לבינאום ולוקליזציה?
הכנתי שאלון קצת שמאפשר לכם לבדוק... האם אתם מוכנים לכתיבת תכנה שתהיה מוכנה להתאמה לתרבויות שונות?
- אני רוצה לייצג מחרוזת, כ־
char *some_text
. מהו המידע שחסר לי? - יש לי מחרוזת
wchar_t *text
אוString text
ב־Java, אני רוצה לקחת את התו הראשון שלה: wchar_t c=text[0]; // C Char c=text.charAt(0); // Java האם זהו קוד נכון? - אני כותב את הקוד הבא: if n==1: print translate("You have one aplle") else: print translate("You have %d apples") % n מה לא בסדר בקוד הזה?
מה לא בסדר בקוד הבא: #include <stdio.h> #include <time.h>
int main() { time_t now_t=time(NULL); struct tm *now=localtime(&now_t); char str_time[32]; strftime(str_time,sizeof(str_time),"%d/%m/%y",now); printf("Today is %s\n",str_time); return 0; }
- מהו גודל הזכרון הנדרש לשמירת תו unicode בודד?
- מהו גודל של wchar_t? (למתכנתי C++/C)?
- מהי גודל של תו unicode בשפת התכנות שאתה אוהב?
- מהו קידוד של מחרוזת (unicode) בשפת התכנות/toolkit שאתה אוהב?
- מה הבדל בין utf-8, utf-16, utf-32?
- מהו אורך התו הארוך ביותר ב־utf8?
- בניתי ספרייה עם שתי פונקציות בלבד. מה לא בסדר בקוד הבא (שתי בעיות לפחות)? extern Char32 to_upper_char(Char32); void to_upper(String str) { for(int i=0;i<str.size();i++) str[i]=to_upper(str[i]); }
- מה לא בסדר בקוד הבא: def print_error_message(message): print translate("Error occured: ")+"“"+translate(message)+"”"
- מה לא בסדר בקוד הזה:
<?php $rtl_langs=array("he","ar","pa"); ?>
...
> ...
- אני רוצה לחתוך את הטקסט בצורה יפה, כך שזה לא ייחתך באמצע המילה: מה לא בסדר בקוד הבא: // Cut nice pice of text wstring cut_nicely(wstring const &orig,int n) { if(orig.size()<=n) return orig; return orig.substr(orig.find_first_of(L" \r\n\t\f",n)); }
Unicode ב־C++ תיקון טעות.
עדכון קטן על תמיכה ב־Unicode ב־C++. למעשה, כשאמרתי בכתבה קודמת שאין כל תמיכה ב־Unicode, טעיתי. דווקא יש תמיכה אם כי היא לא מתקרבת למה ש־ICU נותן.
std::locale נותן מספר ממשקים בפרט: std::ctype<> שמאפשר המרה של case והמרת קידוד בין קידוד מקומי כמו utf-8 או cp1255 למחרוזות של wchar_t. הוא מצליח להמודד עם מקרים יחסית פשוטים כמו המרת "Артём" (השם הפרטי שלי ברוסית) לאותיות גדולות וקטנות בצורה נכונה: АРТЁМ. דבר שכל הכלים, אפילו פחות מוצלחים כמו Python ו־qt3 מצליחים לבצע ללא בעיה.
אבל תמיכה מובנית עדיין לא מצליחה להתמודד עם מקרים מסובכים יותר כמו ß הגרמנית ו־Σ היוונית.
כך שלצרכים הבסיסיים, ניתן להסתפק ב־API של C++ כפישהו, אבל כמובן זאת לא תמיכה מלאה (כמו גם בשפות אחרות, משל Python).
לדוגמה toupper:
// Set global locale
locale::global(locale("en_US.UTF-8"));
// Now we can use locale for various purposes
wchar_t str[]=L"Артём";
use_facet<ctype<wchar_t> >(locale()).toupper(str,str+5);
ייסורי Unicode ב־2009, או תמיכה ב־unicode בסביבות שונות.
אחד הדברים החסרים ביותר ב־C++, מבחינתי, זה העדר תמיכה טובה ב־Unicode. למרות ש־std::wstring ו־std::locale קיימים הם לא נותנים מענה על כל דרישות העבודה עם Unicode.
יש שפות תכנות כמו Python ו־Java בהן התמיכה הזו נחשבת ל"טבעית". אז החלטתי לעשות בדיקה ולבדוק מספר דברים חיוניים בעיבוד טקסט טבעי: החלפה בין אותיות גדולות וקטנות וכן מציאת גבולות המילים. דברים שנראים טריוויאליים עבור אנגלית למעשה הופכים לכלל לא טריויאליים כאשר מדובר בשפות אחרות:
- שינוי אות קטנה לגדולה: ß גרמנית צריכה להפוך ל־SS (שתי אותיות).
- שינוי אות גדולה לקטנה: Σ היוונית הופכת ל־σ במרכז המילה ול־ς בסופה.
- הפרדת מילים לצורך חיתוך הטקסט: 中文 אלה שתי מילים ולא מילה אחת.
בדקתי 6 כלים: ספריית ICU עם API במספר שפות, ספריית glib יחד עם pango עבור C, ספריות Qt3 ו־Qt4 עבור C++, וגם כלים טבעיים של Java, C++ ושל Python.
אקדים ואומר, המקרים הפשוטים כמו המרת: "Артём" (השם הפרטי שלי ברוסית) ל"АРТЁМ" עבדו בכל הכלים ושפות, אבל במקרים יותר מורכבים התוצאות היו כלל לא מעודדות:
כלי | לאותיות גדולות | לאותיות קטנות | גבולות המילים |
---|---|---|---|
C++ | נכשל | נכשל | אין תמיכה |
C++/ICU | הצליח | הצליח | הצליח |
C++/Qt4 | הצליח | נכשל | הצליח |
C++/Qt3 | נכשל | נכשל | אין תמיכה |
C/glib+pango | הצליח | הצליח | נכשל |
Java/JDK | הצליח | הצליח | נכשל |
Java/ICU4j | הצליח | הצליח | הצליח |
Python | נכשל | נכשל | אין תמיכה |
Python/PyICU | הצליח | הצליח | הצליח |
עכשיו פרטים
המשך...האם בסיס הנתונים הוא צוואר הבקבוק של המערכת?
אחת הדעות המקובלות בקרב מפתח Web היא שבסיס הנתונים הוא צוואר בקבוק של המערכות. בסופו של דבר, אם יש המון נתונים והחיפוש לוקח אז אין מה לעשות. ברמה תיאורתית זה נכון.
אם יש לך בסיס נתונים של 1,000,000Gb (שזה ) אז כנראה החזקה מספיק גדולה ואין משמעות לטכנולוגיות אחרות... השאלה היא האם זה נכון?
כידוע, מודל הסיבוכיות הוא עובד יפה כשמדובר במספרים גדולים מספיק ונוהג להתעלם מקבועים. מסתבר שהקבועים הם מספיק חשובים.
כדי להבין את זה, נקח כדוגמה את אחד הפרוייקטי ה־web הגדולים --- wikipedia או ליתר דיוק את חוות השרתים של wikimedia.
נתונים גולמיים:
- בחוות השרתים נמצאים כ־300 שרתים שונים.
- מתוכם במסלול הראשי:
- 95 שרתי Squid -- מה שנקרא Upstream cache שנותנים מענה לכ־78% מכל הבקשות (hit ratio שלהם).
- 144 שרתי Apache+PHP. שנותנים מענה ל־25% הנותרים.
- 20 שרתי MySQL שונים הרצים בתצורות Master Slave השונות.
- השרתים האחרים נותנים מענה לחיפוש, טיפול בקבצים סטטיים ועוד.
- מנגנון memcached משפרים ב־7% הנוספים את היעילות של יצירת התוכן ע"י שרתי Apache.
לכן כיצד שרתי SQL יכולים להוות צוואר בקבוק של המערכת אם הם מהווים פחות מ־10% מכל השרתים הקיימים בחווה? בהנחה שהמערכת שנבנתה ע"י media wiki היא מאוזנת, ברור לנו שרוב העומס החישובי נופל דווקא על שרתי apache המריצים את PHP.
אז האם באמת בסיס הנתונים הוא צוואר הבקבוק?