שימוש נרחב יותר בFirebird

מצאתי בreddit מאמר מאוד ממצה למה אין שימוש נרחב ב Firebird, ואיך אפשר להרחיב את השימוש. בתגובות גיליתי שיש בשנה בן 50,000 למליון הורדות חדשות של firebird, ועוד כמה דברים מעניינים שמומלץ לקרוא (בתגובות עצמן).

כמה נתונים מעניינים שמצאתי בתגובות:

• בברזיל לבד בכנס של firebird יש 500-600 איש המגיעים לכנס.
• האתר למשל לא נמצא בפיתוח, בגלל שכמות מפתחי הליבה של הפרוייקט הוא קטן, ובניגוד למסדי הנתונים ה"אחרים", אין גב מסחרי אמיתי של חברה בפיתוח מסד נתונים – הדבר נעשה תוך התנדבות בלבד (ועדיין הוא עולה על כמה מסדי נתונים מסחריים).
• אומנם ל MySQL יש הרבה כלי ניהול, אבל כמה מהם הם חוצי פלטפורמה כדוגמת Flamerobin ?

מלפון חמוץ

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

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

עם הפעולות חיבור שמשתמשות ב Scenario Outline או "מסגרת תסריט" כמו שקראתי לזה כבר היו בעיות.

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

ניסוי בGIT מי רוצה להצטרף ?

נמאס לי! כאשר אני עושה git clone לוקח לו לפעמים חצי יום להוריד את כל העץ. אז החלתי לחפש קצת יותר מידע על GIT, וגיליתי פרט מעניין, בברירת מחדל הוא עובד על פורט 9418. היות ויש לי תאורטיה שספקיות האינטרנט בארץ מבצעות סוג של מצערת על מידע שעובר לא בפורט 80, 25 (ועוד כמה פורטים "חשובים" כדגומת 443), החלטתי שהגיע הזמן לעשות ניסוי.

הניסוי צריך להיות בצורה הבאה:

1. הקמת "שרת" GIT בשרת אשר נמצא בחו"ל (מי מתנדב לספק שרת כזה ?)
2. לאפשר לאותו repository לעבוד גם ב פורט 80 וגם בפורט 9418
3. לעשות השוואה של 2 הורדות שמתחילות בערך באותו הזמן ולראות מה מגיע יותר מהר

הניסוי צריך להיות שGIT ידבר פעם בפרוטוקל הטבעי שלו, פעם ב rsync, פעם ב HTTP ופעם בFTP.

מטרת הניסוי הוא כמובן להבין האם בפורט 80 יש לנו סיכוי לקבל מהר יותר קוד מקור מ GIT. במידה וכן, אז כנראה שזה הסימן שיש מצערת על כל הפורטים הלא "רגילים" (קרי HTTP, HTTPS, SMTP, IMAP וכו'), הרי אותו שרת, אותו חיבור, אותו ISP אותו הכל, כל מה שמשתנה הוא החיבור בפורט לשרת.

במידה ולא, אז כנראה שצריך לראות מה הבעיות שיש עם GIT, יכול להיות שיש שם משהו שנכתב לא נכון…

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

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

בדיקת קיום מתודה ברובי

טוב את הנושא הבא ידעתי, אבל למה לא לתעד בהמשך לפוסט הקודם.

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

השימוש במתודה תתבצע בצורה הבאה:

100.respond_to?(:to_s) # true

100.respond_to?(:foo) # false

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

מה היא ספסיפיקציה של תוכנה

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

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

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

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

הקוד הפתוח מחפש אתכם

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

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

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

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

לרשימה המלאה של מה נדרש בשביל לארגן את הכנס, ניתן לגשת לכאן.

אפקט העדר, או "כולם משתמשים בזה, אז סימן שיש בזה משהו"

"A person is smart. People are dumb, panicky, dangerous animals, and you know it.
1500 years ago, everyone knew that the Earth was the center of the universe. 500 years ago, everyone knew that the Earth was flat. 15 minutes ago, you knew that humans were alone on this planet. Imagine what you'll "know" tomorrow."
Agent K – Man In Black

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

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

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

לימוד מחודש של רובי חלק ראשון

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

כל "חלק" יתן קישור גם לחלק הקודם.

הבנה של yield ובלוקים

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

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

השימוש ב yield נראה כך:


def explain_yield
arr = [1, 2, 3, 4]
arr.each do |i|
yield i
end
end


הפונקציה למעלה תיתן לנו להשתמש בתוכן של i מבחוץ כל פעם שנשתמש בפונקציה explain_yield עם בלוקים. כלומר:

explain_yield { |i| puts i }

תדפיס עבורינו את הערך ש i העומד כרגע בריצה של הלולאה.

דרך לקבל את כל הערכים היא:

explain_yield do |i|
puts i
end

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

רובי קשה שפה

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

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

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

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

רובי בנוייה לפי 3 צורות פיתוח:

הגברת רדיו אלחוטי

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

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

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

1,500 תגובות

חגיגות 1,500 התגובות בעיצומן עד שחגיגות ה 2,000 יתחילו.

תקליט

זהו שכתוב של הפוסט, ואחרי שראיתי ב TED הרצאה מאוד מעניינת (וחשובה) של פרופסור Lawrence/Larry Lessig החלטתי בעקבות ההרצאה לשכתב כי ההרצאה אומרת בדיוק מה שאני מנסה להגיד, רק בצורה יפה יותר

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

הפונוגרף הוא מכשיר ההקלטה הראשון שאפשר להקליט קול. כאשר הפונוגרף יצא, אמר אדם בשם John Philip Sousa (חובבי מונטי פיתון נהנים מ marsh שהוא כתב) את הדבר הבא לקונגרס האמריקאי:

These talking machines are going to ruin the artistic development of music in this country. When I was a boy…in front of every house in the summer evenings, you would find young people together singing the songs of the day or old songs. Today you hear these infernal machines going night and day. We will not have a vocal cord left. The vocal cord will be eliminated by a process of evolution, as was the tail of man when he came from the ape.

נלקח מ: http://en.wikipedia.org/wiki/John_Philip_Sousa#Other_writing.2C_skills.2C_and_interests

פיתוח מבוסס בדיקות

באתר railcasts שמים דגש מיוחד לאחרונה על פיתוח מבוסס בדיקות ולא בדיקות על בסיס פיתוח. לאחרונה ראיתי הדגמה של עוד 2 גישות שונות ליצירת בדיקות לRails בנוסף למה שהצגתי כבר בעבר.

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

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

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

מוגש כשירות לציבור

אתה האקר ?

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

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

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

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

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

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

ספריית קוד פתוח לטיפול בכרטיסי אשראי

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

מה הכוונה ? מספר כרטיס האשראי שברשותכם אינו מספר שרירותי (או עוקב) שנקבע עבורכם, אלא הוא מכיל כמה כללים:

1. מקדם קבוע (או קבוצה של מקדמים, כלומר הוא לא סתם יתחיל בספרה 30 למשל)
2. אורך קבוע (נגיד 16 ספרות או 13 ספרות)
3. סיכום מספרים קבוע (בד"כ אם כי לא מחייב, אלגוריתם luhn -> אותו אלגוריתם של מספר תעודת הזהות הישראלית, רק מספר תעודת הזהות הישראלית שינתה חוק אחד באלגוריתם)
4. ספרות ביקרות לבדוק האם הכרטיס נמצא ליידכם (אני לא חושב שזו בדיקה טובה, כי אפשר לרשום אותם כמו שאפשר לרשום את המספר כרטיס אשראי שלכם), אשר בנויות על אלגוריתם שדורש יותר מידי עבודה ממה שאני מוכן להשקיע לבד, אבל אם יתרמו לי קוד שעושה בדיקה, אז אוסיף אותו לספרייה

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

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

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

שוחררה הגרסה 2.2.4 למהדר FPC

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

השינויים שנכנסו לגרסה החדשה הינם:

• כל property בחלק ה published שהוא Boolean או Enum יקבל ערך ברירת מחדל במידה ואין שימוש ב default.
  property שהוא בוליאני יקבל בברירת מחדל ערך false
  property שהוא enum יקבל בברירת מחדל ערך של 0
• המחלקות של TField עם ה property של Size ו DataSize, וכן המתודות המטפלות בגודל של השדות עברו מ Word ל Integer בשביל תאימות לדלפי
• ההתנהגות של TProcess בכל מערכות unix (כולל לינוקס) שונתה, ועכשיו אין חיפוש בספרייה המקומית לקובץ הרצה, אלא אם צויין במפורש בקוד. בעיה זו פותרת בעיית אבטחה בה תוכנית כדוגמת ls קיימת גם בספרייה המקומית וגם ב /bin/ וTProcess יריץ את התוכנית בספרייה הנוכחית במקום מהספרייה /bin/
• הפקודה round מחזירה עכשיו ערך לפי לצורה שדלפי מחזיר. ניתן לשנות את ההתנהגות על ידי הגדרה של Math.SetRoundMode

בתוספות אנחנו יכולים למצוא את:

10 חוקים להאקר המתחיל

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

ניסוי בGPS של Neo FreeRunner

החלטתי לעשות כמה ניסויים ל OpenMoko ול Tango GPS היות ובחול המועד אני רוצה לצאת ולשחק קצת ב Geo Caching (במידה וכמה חברים לא יבריזו לי הפעם).

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

הדבר הנחמד במעבד GPS של Neo, הוא בכך שהוא מזהה תזוזה (גם עדינה מאוד), ואת כיוון התזוזה ביחס לצפון. יש עם זה כמה בעיות (או אלי זה Tango), אבל הוא מזהה את ההליכה שלי בתוך הבית, ואפשר לראות מסלול אדום של כל חדר או המסדרון שהייתי בו עם Neo בתוך הבית. אבל אני חייב לציין שמהירות ההליכה שלי קצת מוזרה לי לפי הצורה ש Tango הציג. הוא הציג רוב הזמן שהלכתי בין 6-10 קמ"ש. אבל בממוצע הוא כתב שהלכתי 5.70 קמ"ש בממוצע. ואם זה לא מספיק מוזר, אז כשהוא נמצא על השולחן ולא זז (נשבע לכם) הוא אומר שהשולחן זז בין 1 ל2 קמ"ש.

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

בזמן הטיול גיליתי של Neo חסר דבר אחד מאוד מאוד מאוד מאוד חשוב (בייחוד בקיץ), ואני מבין שבגלל זה הפסיקו את הפיתוח של GTA03 וחזרו להמשיך לפתח את GTA02: גלאי נחשים!

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

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

להבין את load average ביוניקס

כל מי שעובד ביוניקס מספיק זמן מגלה את load average. ניתן להגיע אליו דרך הפקודות top, procinfo, w ו uptime. העניין הוא שלא הרבה יודעים מה זה בעצם אומר. אז אני אנסה להסביר כאן בקצרה (ובצורה מאוד לא ממצה, אבל מספיק ברורה אני מקווה) מה זה אומר.

ובכן אם נסתכל על ה load average אנחנו נראה שהוא מורכב מ3 קבוצות של מספרים:

load average: 0.40, 0.46, 0.47

הקבוצות מייצגות זמן. הקבוצה הראשונה מייצגת דקה, הקבוצה השנייה 5 דקות והקבוצה השלישית 15 דקות.

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

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

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

לקריאה מקיפה יותר אתם מוזמנים לגשת לקישורים הבאים:

http://www.lifeaftercoffee.com/2006/03/13/unix-load-averages-explained/

http://www.crucialp.com/resources/tutorials/server-administration/server-loads-explained-linux-unix.php

http://www.teamquest.com/resources/gunther/display/5/index.htm

http://en.wikipedia.org/wiki/Load_(computing)

תמיכה של FPC ב OpenMoko

כאשר קיבלתי את Neo התחלתי לבדוק איך לגרום ל FPC לעבוד איתו. בהתחלה שלחתי הודעות ברשימת הדיוור, וגיליתי שגם בני (בנידיקט) מנסה לעשות אותו הדבר, רק לו יש הרבה יותר ניסיון ממני בעובדה עם Embedded.  מסתבר שבכלל יש הרבה מפתחי Embedded בקהילת ה FPC. לכמה מהם אפילו יש Free Runner .

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

הסיבה לקושי הוא בכך שיש 2 סוגי ABI עבור ARM בתמיכה של libc, ו FPC תומכת הרבה שנים כבר בגישה הישנה יותר של ARM אבל כמעט בכלל לא בגרסה החדשה.

הגרסאות השונות נקראות:

1. OABI – תמיכה טובה במעבדי ARM ישנים, אבל אין תמיכה בהרבה תכונות של מעבדי הARM החדשים יותר (FPC תומכת בצורה טובה ב ABI הזה)
2. EABI – תמיכה חדשה יותר למעבדי ARM עם יכולות טובות יותר. למשל תמיכה במעבד מתמטי ונקודות צפות ועוד הרבה דברים (ל FPC אין תמיכה טובה בו, היות והמימוש לתמיכה מאוד חדש וכמעט ולא נבדק)

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

בקיצור, בני השקיע הרבה יותר ממני והבין איך אפשר לבנות על לינוקס את FPC בשביל שהוא יתמוך ב OpenMoko . לצרוך התמיכה הזו צריך להדר את binutils בצורה הבאה: