ארכיון חודשי: דצמבר 2010

עננים בצבע כרום

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

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

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

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

אז מה גוגל מציעים לנו ? ובכן אם נאבד חתול, יהיה אפשר לקחת פזל שלו וליצור ברשת הודעה לחפש אותו, תוך כדי שיחה עם חברים, ואה, יש גם גלידה, וקפה, ואפשר לעשות על האש וכו'… שוב הצד הסרקסטי שלי תופס פעולה. מה שאנחנו מקבלים מגוגל זה כלי לאיבוד שליטה בצורה מלאה על המידע שלנו, ובכך אנחנו נרוויח מזה שנקבל הצעות מחיר ומוצרים המתאימים לרצונות שלנו, גם אם אנחנו עדיין לא יודעים שאלו הרצונות שלנו. הרי ההתמחות של גוגל זה כריית מידע ועיבודו. למעשה גם חברות האשראי מתמחות בזה (מכירים את התלושים שאתם מקבלים בייחד עם החיוב אליכם הביתה ?). אם תהיתם איך הדבר נעשה, אז יש מסד נתונים בעל 4 (או יותר -> אורי) ממדים (נקרא cube או בשמו המלא Online analytical processing cube) והתפקיד שלו להצליב מידע שעל פניו נראה לא קשור בייחד למידע אחיד. כלומר נגיד ורכשתם המבורגר פעם אחת בחיים שלכם, אבל תמיד אתם קונים שווארמה, אז תתחילו לראות פרסומות לגבי שווארמה (והתעלמות מוחלטת מהמבורגר, פיצה וכו') וזה התפקיד של הcube להביא את המידע המוצלב הזה ממקורות לא קשורים (שימוש ב30,000 אתרים יכולים להגיד בצורה קרובה אם התגובה האנונימית ששלחם לטמקא, היא אתם או מישהו אחר).

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

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

איך אתם עושים את זה בשפה שלכם ?

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

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

כלומר אם ניקח את הפוסט הישן שלי של התרגיל הבא:

var c : Currency;
begin
C := 0.1 + 0.2;
writeln(C:2:2);
end.

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

לקוח גרפי ל xml-rpc

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

החלטתי ללכת על לזרוס היות ודבר ראשון זה לקוח גרפי (במקום ליצור ראשי HTTP ב telnet או עבודה עם live http headers ב Firefox שהייתי עושה עד אז) אשר לדעתי עדיף על פני סביבה טקסטואלית, כלומר כאן היה מקום לדעתי ללקוח גרפי, וגם בזכות שיחסית זה לא דרש ממני הרבה עבודה. למעשה זה לקח ממני שעה כולל תיקון באג בספריית ה HTTP שעד אז לא הכרתי את הקוד שלה (שלקח את רוב הזמן שלי).

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

אחד הדברים המדהימים שגיליתי על התוכנה אשר הודרה כמובן באמצעות FPC, היא שלמרות שהתוכנה עברה 4 הפצות לינוקס (אובונטו, מנדריבה, דביאן וארץ') ובתוך ההפצות גם גרסאות שונות של אותה הפצה, ו3 מחשבים שונים (מחשב שולחני, מחשב נישא, ומחשב של לקוח בתוך VirtualBox -> כן גם לקוחות שלי השתמשו בה לבדיקות קוד שלהם), אבל כל עוד ה API של GTK2 (במקרה שלי -> אני מהדר לסביבה הגרפית הזו) לא השתנה, התוכנה עבדה ללא בעיה. רק כאשר ה API של GTK2 השתנה קצת, הייתי צריך להדר את התוכנה מחדש בלי לשנות את הקוד שלי, והכל חזר להיות רגיל.

אז אני עובד עם התוכנה הזו שכתבתי לפני 3.5 שנים (או קצת יותר), ואז התחלתי לכתוב גם תוכנות אשר משתמשות ב REST וב JSON לבקשת הלקוחות, ופתאום התוכנה לצערי כבר לא מתאימה לזה. אז לקחתי את הקוד והתחלתי לעשות לו refactoring וליצור לו תמיכה במספר RPC שונים כדוגמת JSON בנוסף ל XMLRPC, ושליחה של טקסט נקי (text/plain). כרגע נשאר לי להוסיף תמיכה לעבודה עם REST "נקי" (כלומר פרמטרים ועבודה עם GET, POST, DELETE וכו'), והתוכנה שוב תהיה שלמה לצרכים שלי. יותר מזה , הרבה מעבודות ה refactoring היו בשביל להחליף ספריית HTTP. אמנם אני לא מת עליה (על הספרייה החדשה), אבל היא גמישה יותר לצרכים שלי (עד שאלס ישכתב את הספריית HTTP ואולי אחזור לlNet),  ובנוסף הגישה עכשיו של התוכנה גמישה יותר, כך שניתן להוסיף לה תכונות חדשות כאשר הדבר לא ידרוש ממני לשכתב קוד בצורה דרסטית כמו העבודה כאן.

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

את הקוד תוכלו למצוא בכתובת הבאה:

https://github.com/ik5/xmlrpc-client-ui

לאן הרוח הטכנולוגית נושבת ?

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

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

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

המשתמש אשם

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

לאחר מספר באגים כאלו, הפסקתי לדווח באגים למוזילה, היות וראיתי שהם לא מכבדים אותי, ואת דיווחי הבאגים, אז חבל על האנרגיה. העניין הוא שהזלזול המתמשך במשתמשים, זליגות זיכרון (או אולי הצורך בעוד זיכרון ללא שיחרור זיכרון שלא בשימוש), חוסר חידוש אמיתי בשוק, ורכיבה על זרי הדפנה על המאבק ב IE, הובילו לכך שכיום גוגל עם דפדפן Chrom מובילות את המאבק טוב יותר מאשר מוזילה. למשל מיקרוסופט, אופרה וגוגל (בייחד עם שאר מפתחי webkit) הבינו שהעתיד הנוכחי (כלומר המצב הנוכחי שכולם אומרים שהוא העתיד, למרות שהוא ההווה), רוב התוכנות מתחילות להתרחש בצד המשתמש ולא בצד השרת, ולכן כל הזמן מחפשות דרכים להאיץ את מנוע הJavascript שלהן. ויום אחד מוזילה מצאו את עצמם מאחור (או למעלה מידי בגרף) מבחינת ביצועים, אז הם החליטו לכתוב מחדש את spidermonkey – מנוע לJavascript שצריך להיות מהיר.

אבל העניין הוא שעוד דבר אחד חשוב מאוד בצד מוזילה, שהם התחילו את העניין, אבל לא הבינו את המשמשעות האמיתית מעבר לשיווק בשל מלחמתם בIE וזה תוספים. במוזילה התוספים כתובים בשפת Javascript, ובשביל ממשק גרפי, הם משתמשים ב"תוסף" בשם XUL אשר אמור לשמש כממשק גרפי עבור התוכנות. הבעיה היא שיש הרבה בעיות זיכרון וביצועים עם התוספים של מוזילה. כלומר מוזילה כיום איטית מאוד, מנופחת מידי (במקור הם כתבו את Firefox להחליף את SeaMonkey או Mozilla Suite אשר הכיל יותר מידי דברים בפנים, כמו עורך HTML, ממשק לדוא"ל ועוד), אבל מאז הרבה יובש עבר בכינרת וגם שריפות ברמל, ולמרות שאין לFirefox את כל אלו, הוא מנופח מידי ומגיב לאט מידי, וההשקעה בו בלינוקס מועטה מידי. כלומר אם נריץ ב VirtualBox מערכת הפעלה בשם Windows נכניס לה את אותן התוספים שיש לי באותה גרסת Firefox, ונריץ בייחד את Firefox כאן בלינוקס (מכונה אמיתית) בWindows עדיין Firefox יהיה מהיר וטוב יותר מאשר בלינוקס, למרות שבWindows הוא רץ תחת מכונה ווירטואלית. לפי עידן, בעיה היא בכם -> המשתמשים. אז יש לי פתרון פשוט, למה שלא נפסיק להשתמש ב Firefox, ואז אנחנו כמשתמשים נפסיק להיות הבעיה של הפרוייקט, במקום שהפרוייקט יתחיל לספק כלים נורמאליים לנו המשתמשים ויפתור את הבעיות השונות שיש ?