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

תרגום Essential Pascal לעברית

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

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

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

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

את התרגום העברי של עידו, ניתן להשיג בכתובת הזו.

הבעיות של מערכת החינוך – חלק ג' (הבעיות עצמן)

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

The problems that exist in the world today cannot be solved by the level of thinking that created them.
Albert Einstein

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

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

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

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

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

הבעיות של מערכת החינוך – חלק ב' (המציאות כיום)

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

Data is not information, Information is not knowledge, Knowledge is not understanding, Understanding is not wisdom.
Cliff Stoll & Gary Schubert

אם אקח את ה20 שנה האחרונות כנקודת ציון (1990-2010), ניתן לראות כי חלה מהפכה עצומה באופן בו אנו חיים. ראשית יש לנו יותר כלים לשעות הפנאי – מכשירים אשר עוזרים לנו למלא את חלל הזמן לאחר שאנו מסיימים עבודה, לימודים וכדומה. בניגוד לסוף שנות ה70 ותחילת שנות ה80 בהן טלפון עדיין לא היה נפוץ ובישראל לקבל קו טלפון היה יכול לקחת קרוב לשנה ובמקרה הרע גם שנתיים מרגע ההזמנה ועד ההתקנה. לא לכולם הייתה טלוויזיה, ואם הייתה עבור חלק לא מבוטל היא הייתה שחור לבן, החוויה כללה בעיות קליטה וערוץ בודד. היו מכשירי רדיו אשר אפשרו צריכת מידע, בתי קולנוע, עיתונים, ספרים ופחות או יותר זהו. כך שלא היו כלים רבים (יחסית) "להתנתק" או למלא את חלל הזמן לאחר שעות הפעילות השונות, ומילאו אותם בדרכים אחרות.

בערך בשנות ה90, החלה מהפכה בישראל (רק אודותיה אדון כאן). בין השינויים: הטלוויזיה בכבלים נכנסה לחיינו והפכה את הטלוויזיה למוצר צריכה מרובה ערוצים. טלפון נהפך זמין לכל דורש ואף קיבלנו את התחלת הסלולרי עם חברה שעד היום שמה משמש כשם גנאי לתאור מכשיר סלולרי. המחשב האישי החל להיכנס לבתים בישראל בייתר שאת, בהתחלה לאנשים במעמד טיפה גבוה יותר, אח"כ לאט לאט טפטף לשכבות הנמוכות יותר. עם המחשב נכנס גם המודם (אנלוגי במהירויות של 9,600 -14,400 ואח"כ גם 33,600 והכוונה היא כמות ביטים בשנייה -> אני עדיין אדם טכני ;)). נוסף ערוץ טלוויזיה למדינה (לחסרי הכבלים) וקווי טלפון בין עירוניים עברו מתשתית יקרה לתשתית זולה יותר ושיחות בין עירוניות שהיו יקרות מאוד, גם בגלל שלא כולם היו יכולים להתקשר בו זמנית עם כולם, פתאום הפכו לנגישות עם יותר ערוצי תקשורת בו זמנית.

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

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

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

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

הבעיות של מערכת החינוך – חלק א' (ההיסטוריה של מערכת החינוך)

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

A generation which ignores history has no past and no future.
Robert Heinlein

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

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

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

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

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

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

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

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

fpMake

fpMake היא מערכת בנייה, יצירת חבילות ופריסתם שכתובה בפסקל, אבל לא רק עבורה. הרעיון הוא ליצור מערכת בניה הגיונית ונוחה לעבודה, דבר שלדעתי ודעת אנשים נוספים אינו מתקיים עם gnu-Make.

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

למשל בפסקל אני מכניס לתוך הקוד שלי את ההוראות למהדר, בעוד שבשפות כמו C ו ++C, יש לנו את AutoConf עבור זה. למשל אני יכול בפסקל להגיד למהדר לאיזה ספרייה קישרתי את הקוד שלי, כלומר קוד X עושה binding לפונקציה Y שנמצאת בספרייה Z. אני יכול להגיד לו גם שהקוד שלי הוא בעצם ספרייה משותפת (או סטטית), והכל בקוד שלי, אני עדיין לא צריך הוראות מיוחדות מחוץ לקוד.

המעכת מחולקת ל2: fpMake ו fpPkg כאשר האחרונה, היא בעצם הספרייה שאחראית על יצירת החבילות עצמם, בעוד שfpMake כאמור אחראית על הבנייה.

אז איך בעצם עובדים עם מערכת הבניה ?

program fpmake;
uses fpmkunit;
 
Var
 P : TPackage;
 T : TTarget;
 
begin
  With Installer do
  begin:= AddPackage('my-nice-program');
    P.OSes := [win32,openbsd,netbsd,freebsd,darwin,linux];:= P.Targets.AddUnit('myunit');
    T.ResourceStrings := True;:= P.Targets.AddUnit('myprogram');
    T.Dependencies.Add('myunit');
    Run;
  end;
end.

כמו שאפשר לראות זה פשוט מידי. מה שקורה כאן, הוא שאנחנו נותנים הוראות איך ליצור חבילה לתוכנה שלנו, אשר קראנו לה my-nice-program שזו בעצם חבילה (תכנותית) שמאגדת בתוכה את כל המידע על התוכנה שלנו. אמרנו שהיא מסוגלת לעבוד עם מערכות ההפעלה win32, openbsd, netbsd וכו', אמרנו שהיא מכילה את הקבצים myunit וmyprogram. ואמרנו לה שאנחנו פשוט חייבים את myunit.

נשמור את המידע הזה לקובץ בשם fpmake.pp ונריץ את הפקודה:

$ fppkg build

ותהיה לנו חבילה שאפשר להתקין אותה לאחר מכן במערכת שנרצה.

אם נרצה לספק שם אחר, אז נריץ את הקוד בצורה הבאה:

$ fpc <mybuild_code>

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

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

לעוד קריאה אני ממלץ לכם לקרוא את הקישורים שסיפקתי בנושא.

שדה עם זהות

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

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

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

אז איך זה נראה ? התחביר היבש הוא כזה:

<column definition> ::= <name> <type> GENERATED BY DEFAULT AS IDENTITY <constraints>

בפועל, התחביר יראה בצורה הבאה:

create table objects (
  id integer generated by default as identity primary key,
  name varchar(15)
);

insert into objects (name) values ('Table');
insert into objects (name) values ('Book');
insert into objects (id, name) values (10, 'Computer');

select * from objects;
          ID NAME
============ ===============
           1 Table
           2 Book
          10 Computer

וההגבלות הן מאוד פשוטות: צריך מספר שיכול להתחיל ב0, כלומר:

smallint, integer, bigint, numeric(x, 0) , decimal(x, 0)

בנוסף, השדה לא יכול להיות שדה מחושב (COMPUTED), היות ואי אפשר להשתמש במידע של שדות אחרים, וכן לא ניתן לתת לו ערך ברירת מחדל.

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

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

מה כלי העבודה שלך ?

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

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

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

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

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

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

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

האם אתם אי פעם עשיתם הפסקה וחשבתם בעצם מה אתם חייבים בשביל לבצע את העבודה שלכם ובלעדיה לא תוכלו לעשות שום דבר ?

באג שהתגלה כפיטצ'ר

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

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

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

ועל זה נאמר באג שהפך לפיטצ'ר, או בגרסה המוכרת יותר, "בא לקלל ויצא מברך" 🙂

שדות בוליאניים ב firebird

גרסה 3 של Firebird הולכת בין היתר להכיל שדות מסוג Boolean בתוכם. זה הפיטצ'ר שהיה במקום השלישי מבחינת הקולות בבקשות לפיתוח Firebird – כאמור בגרסה 3 הוא מתקיים.

המפתח של התמיכה, השקיע המון מחשבה בנושא ולא יישם את התמיכה "על רגל אחת". ובכך הוא הכיר לנו טיפוס מסוג BOOLEAN, אשר יכול להכיל ערכים של TRUE, FALSE ו UNKNOWN/NULL (שניהם זהים בהתנהגות שלהם).

בנוסף, שדה מסוג BOOLEAN יכול להיות מפתח וכך אפשר לחפש לפיו, לחתוך לפיו, לסדר לפיו וכיוב'…

על מנת לחפש עם מפתח מסוג בוליאני, הוא יצר פעולה חדשה בשם IS כלומר:

field IS FALSE
field IS TRUE
field IS UNKNOWN

ובייחד עם זה אפשר להמיר שדה בוליאני למחרוזת, כלומר הביטוי הבא:

"field1 OR field2" and "NOT field1"

הוא חוקי לגמרי.

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

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

fpWeb – שלום עולם

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

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

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

כרום או כרומיום, הוא אלמנט כימי הנמצא בטבלה המחזורית כ 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, ואז אנחנו כמשתמשים נפסיק להיות הבעיה של הפרוייקט, במקום שהפרוייקט יתחיל לספק כלים נורמאליים לנו המשתמשים ויפתור את הבעיות השונות שיש ?