טיפ שני ב Firebird

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

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

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

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

אז לשם שינוי השם, אנחנו נשתמש ב 2 השאילתות הבאות:

UPDATE RDB$RELATIONS
SET RDB$RELATION_NAME='NEWNAME'

WHERE RDB$RELATION_NAME='OLDNAME';
COMMIT;


UPDATE RDB$RELATION_FIELDS
SET RDB$RELATION_NAME='NEWNAME'

WHERE RDB$RELATION_NAME='OLDNAME' and RDB$SYSTEM_FLAG=0;
COMMIT;

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

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

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

בדיקת תקינות Javascript/EmcaScript

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

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

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

טיפים ב Firebird חלק ראשון

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

select first skip

במידה וצריך להחזיר את ה10 רשומות הראשונות, אפשר להשתמש ב מילה השמורה של first בצורה הבאה:

select first 10 * from table;

ונקבל את ה10 רשומות ראשונות

במידה ונרצה להחזיר רק מהרשומה הרביעית, נשתמש ב select skip:

select skip  3 * from table;

ונקבל את הרשומה הרביעית ומעלה.

ניתן גם לשלב בין first לבין skip:

select first 10 skip 3 * from table;

ונקבל את 10 הרשומות הראשונות מהרשומה הרביעית ועד לרשומה ה13

להעלות את Ruby on Rails על סולם

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

Gregg Pollack מ new relic יצר 14 screen cast (אני מחפש מילה בעברית שתסביר טוב מה זה) על איך לגרום לrails לעלות בסולם השימוש, או scale בלשון העם.

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

את ה video cast אפשר למצוא כאן.

גישה טכנולוגית

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

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

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

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

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

עבודה עם מחרוזת מרובת בתים ברובי

במידה שאתם צריכים לעבוד עם תווי multi-byte  כדוגמת עברית ב UTF-8, בברירת מחדל רובי לא יודע לזהות שזו כוונתכם.

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

$ gem install unicode

ועכשיו בקוד יש להוסיף את 2 השורות הבאות:

require 'unicode'
$KCODE = 'UTF-8'

ועכשיו אם נרצה לעבור על תווים שהם utf-8, נוכל לעשות זאת ללא בעיה:

'שלום עולם'.each_char do |ch|
puts ch
end
ש
ל
ו
ם

ע
ו
ל
ם

ועכשיו אפשר לדעת שהמחרוזת יודעת לזהות מחרוזת מרובת תווים.

חשוב לדעת שהמודול אינו מושלם ואינו תומך בצורה מלאה בכל המתודות של String.

מלפפון עברי

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

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

עכשיו רק צריך להתרגל לכתוב בדיקות וכבר אין תירוצים 🙂

lambda ללא λ

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

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

בואו נכתוב פונקציה מאוד פשוטה:

function ReturnSomething : integer;
var
X : integer;


procedure print_double_X;
begin
writeln(X * 2);
end;


begin
X := 2;
print_double_X; { print 4 }
end;

כמו שאפשר לראות, יש לי תמיכה ב nested functions בפסקל ואם אני כותב משתנים לפני ההגדרה, אז אפשר גם לגשת אליהם דרך אותן פונקציות, מה שבעצם גורם למצב שמתנהג כמעט לגמרי זהה ל lambda. כמובן שתלוי עד כמה "גבוהה" רוצים להגיע כאשר מדברים על lambda, אבל אני יכול ליצור עכשיו בתוך nested function עוד nested function וכו' וככה להשיג הרבה אפקטים זהים כמעט ב100%.

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

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

צעדים ראשונים בתכנות מבוסס בדיקות

לאחרונה התחלתי ללמוד על פיתוח מבוסס בדיקות. מה הכוונה בפיתוח מבוסס בדיקות ?

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

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

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

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

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

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

BucketWise – תוכנה לניהול מידע פיננסי אישי

BucketWise היא תוכנת קוד פתוח מבוססת web שנכתבה ב Ruby On Rails, ותפקידה הוא לספק ניהול אישי (לא עסקי) של כל המידע הפיננסי של המשתמשים בה.  התוכנה מאפשרת ניהול משתמשים שונים במערכת וכן ריבוי חשבונות לכל משתמש.

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

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

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

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

בשביל להתקין את תלויות התוכנה נוכל להשתמש ב gem של רובי (אלא אם יש לנו חבילות קיימות בהפצה שבה אנחנו משתמשים) בצורה הבאה:

$ sudo gem install <package name>

כך שאת התלויות הבאות נוכל להתקין בצורה הבאה:

$ sudo gem install capistrano rake rails highline sqlite3-ruby

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

אפשר לראות כאן ו כאן איך לעבוד עם התוכנה.

Double Commander

בעבר (כמעט שנה) דיברתי על Tux Commander שמנסה לספק את היכולות של total commander ללינוקס.

עוד תוכנת קוד פתוח מאוד מעניינת שהיא חוצה פלטפורמות (וגם מספקת יכולת לעבוד בלינוקס עם GTK ו QT) היא Double Commander.

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

כמו Total Commander ו ‎ Tux Commander, גם תוכנה זו כתובה עם FPC ולזרוס.

אתם מוזמנים לקרוא עליה עוד ולהוריד אותה מכאן.

ירושה, העמסה ושיכתוב מתודות במחלקות פסקל

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

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

Where have all the user friendlines go ?

I've been going over some RSS feeds, and I found the following link.

This link is about a technical book from the 80's. I remember something from the 80's regarding books: they where more then just pages, but interactive, and many time more friendly then any good  book or tutorial that we have today.

It makes me wonder, where did we loose the simplicity approach and returend to the more "clean" one, that books must be plain text, not interactive etc…

A first release of my (un quick) start guide for Firebird SQL in Hebrew

I have released my most waited guide (since the last one at least) regarding the Firebird SQL database.

The guide itself is in the Hebrew language with the aim of being a starting point for users who wishes to know how to start working with the Firebird SQL database. The guide itself does not come as a replacement for the official documentation of Firebird SQL, but as a starting point in a native language, so it will be much easier for people to work with the database and it's official documentation.

The guide itself will be added gradually to some open source web sites for guides in Israel (The hitchhiker guide to the computers (aka guides.co.il), Penguin and Wikibooks -> any other web sites that I do not know about are also welcome to publish it), and also in my own personal web site.

The odt and pdf formats are already available for download, and unless mentioned otherwise will always contain the latest version of the guide.

The guide itself is released under Creative Commons Share Alike

I'm planning also to write some smaller guides for using the tools arriving with Firebird SQL, and some additional things that I think should be in their own guide/tutorials.

2 הכרזות

יש לי 2  הכרזות לבצע, נלך מהקלה לפחות קלה.

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

ברצוני להודות לאנשים הבאים:

• אור
• אסף ספיר
• יחזקאל ברנט
• מאיר קרחילי
• שלומי פיש

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

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

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

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

[ציניות]

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

[/ציניות]

תכנון ממשקי משתמש גרפיים

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

אני זוכר מישהו שזגזג בין לבחור בלזרוס לבין בחירה בכל טכנולוגיה אחרת, כאשר מישהו אומר לו משהו על glade, והוא מייד בא ואומר לי "glade יותר טוב כי יש לו את X" ואז אני אומר לו איך לבצע אותו הדבר בלזרוס, והוא חוזר לאותו אדם ואומר לו ש"לזרוס יותר טוב כי יש לו גם את Y " וחוזר חלילה…

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

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

ניסוי ב GIT – ההתחלה

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

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

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

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

האם אתם יכולים לאשר שגם לכם זה קורה או שלא ?