ארכיון חודשי: יולי 2008

לשטוף את הסבון

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

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

אחת התכונות העיקריות של .net היא השימוש בטכנולוגיית SOAP גם כאשר ממש לא צריך. למי שאינו יודע, השם הלא מתאים של SOAP אומר Simple Access Object Protocol. הטכנולוגיה כל כך פשוטה, עד שהיא דורשת מבנה מיוחד של ראשי HTTP, מעטפות, קבצי סכמות/הוראות (קובץ wsdl) וכו' בשביל לשלוח נתונים באמצעות פורמט XML בסופו של דבר.

יש אמנם שימושים לSOAP, מעטים אבל הם קיימים (למשל RPC מסובך יתר על המידה שבו צריך להעביר מידע על אובייקטים). הבעיה היא שבעולם ה .net גם כאשר אין צורך בכלל להשתמש ב XML, שלא לדבר שלא צריך להשתמש ב SOAP, עדין יותר פשוט בכלים שמיקרוסופט מספקת להשתמש בSOAP, מאשר משהו חליפי כדוגמת פעולת HTTP GET פשוטה בה מקבלים תשובה ממש פשוטה (בדיוק המקרה שקיים אצלי כרגע), XML-RPC ועוד טכנולוגיות רבות טובות ופשוטות יותר.

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

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

סיכום ההרצאה על רובי

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

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

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

Freelancer

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

אם בנימין פרנקלין אמר פעם שהטעות הראשונה כשעושים עסקים זה להיכנס לתחום (The first mistake in public business is the going into it. Ben Franklin), אז האתר הזה מנסה לעזור להתנהל מול הטעות הזו.

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

אוגוסט פנגווין 2008 חלק א'

ביום שישי הבא (כלומר ה1 לאוגוסט) יערך כנס אוגוסט פנגווין ה7 במספר (רם-און, השנה אני מכוון ליותר מ5 אנשים נוספים שיגיעו לכנס, בזכות [?] הבלוג שלי). השנה יש מהלך שגרם להרבה מאוד דיונים די לא מפתיעים בנושא.

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

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

מתכנתי copy paste

במרץ 2007 הייתי בכנס האסטריסק הישראלי הראשון. בחלק הסופי של הכנס, היה מתכנת שניסה להבין איך לעבוד עם אסטריסק, אבל מילים פשוטות כמו RFC לינוקס וכו' היו דברים שהוא לא הכיר, למרות שהוא אמר שהוא מתכנת למעלה מ20 שנה.

אני לא זוכר אם זה היה צפריר כהן או מני ליבנה שהגדירו את הגישה של אותו מתכנת, בתור מתכנת Copy Paste. הכוונה במתכנת כזה, הוא שהמתכנת לא באמת מבין מה הוא עושה, ואיך דברים עובדים, אלא הוא פועל לפי איך שאומרים לו לפעול. למשל הוא צריך לכתוב תוכנית שמדפיסה Hello world על המסך, אז הוא לא ינסה להבין כיצד מתחילים תוכנית בשפה שהוא צריך, וכיצד מדפיסים על המסך, אלא הוא יחפש מישהו שעשה את זה פעם, יעתיק וידביק את הקוד, ויגיד שיש לו תוכנית שעושה את מה שצריך.
למעשה מתכנת copy paste יודע רק מה שהוא חייב בשביל להגדיר את עצמו בתור מתכת, ולא ינסה ללמוד שום דבר מעבר לכך, ובהרבה מיקרים גם לא יהיה מסוגל לעשות את זה אם יחפוץ בכך.

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

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

אני לא מבין איך כל כך הרבה אירוגנים יכולים להרשות לעצמם אנשים כל כך לא מקצועיים.

בעיות הקוד הפתוח

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

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

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

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

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

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

נשיקות לתער של אוקהם

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

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

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

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

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

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

למשל אני נוהג לתת את המשימה הבאה לאנשים (ש99% מהם נפלו עד עכשיו, וכמה גם אמרו לי שאני פישטתי את הדברים הרבה יותר מידי): יש ריבוע, משולש ועיגול. כיצד תגידו למחשב להניח את הריבוע, ועליו את העיגול ועל העיגול את המשלוש ?

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

מלכוד 22 בעסקים

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

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

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

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

שוחררה FPC 2.2.2 RC2

לפני חודש שוחררה גרסת בדיקה ל FPC 2.2.2, והיום שוחררה גרסת ניסוי נוספת.

בין השינויים בגרסה זו ניתן למצוא:

המרת widechar ל char והפוך

אפשרות להמיר בין wide char לבין תו "רגיל" והפוך, בין תו "רגיל" לבין wide char. ההמרה מתרגמת (בניגוד לעבר) את המידע בהתאם להמרה שמתבצעת בצורה אוטומטית.

דוגמא:

ansi_char := char(wide_char)

ההמרה תמיד ממירה את התו מערך ה widechar לתו שנמצא כרגע ב code page שבו התוכנה נמצאת. ההמרה מתבצעת באמצעות מנהל ה widestring שבו מוגדרים פונקציות ההמרה (שכמובן אפשר לשנות בהתאם לצורך).

ביצוע typecast לקבוע סידורי

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

דוגמא:

TMyIP = record
Network, classA, ClassB, ClassC : Byte;
end;
var MyIP : TMyIP;
MyIP := TMyIP(10003445);

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

שינוי גודל של קבוצות

נוספה אפשרות לקבוע גודל של sets בהתאם לצורך, דבר שאומר שהגודל משתנה בהתאם לצורך.

עוד פרטים ניתן למצוא כאן.

ניתן להוריד את הגרסה החדשה כאן.
או להוריד מ SVN:

svn co http://svn.freepascal.org/svn/fpc/tags/release_2_2_2_rc2/ fpc_2_2_2_rc2

להורדה של "שחרור" ניתן להוריד מsvn:

svn co http://svn.freepascal.org/svn/fpc/branches/rc_2_2_2/ rc_2_2_2