ארכיון חודשי: אפריל 2009

שימוש נרחב יותר ב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 מילים שונות, אלא להסביר מה זה גבוהה.

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

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

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

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

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

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

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

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

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

"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 צורות פיתוח: להמשיך לקרוא

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

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

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

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

תקליט

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

מה השתנה הממשק הגרפי מכל הממשקים האחרים [קושייה לפסח] ?

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

הלילה הזה, אתם מוזמנים להנות ממבט על ממשק גרפי ב1981 מבית Xerox.

אתם תגלו שלא באמת השתנה הרבה ב27 שנים האחרונות מבחינת ממשק גרפי.

חג שמח

The new age of SQL Injection

Researchers at Black-Hat have published a demonstration on how to harm an entire server instead of just hurting the data at the database itself.

The attack vector uses the SQL Injection attack and trigger a buffer overflow, and from that point, the attackers can do what ever they like.

The vulnerability exists on the following tested databases:

  • MS-SQL Server
  • PostgreSQL
  • MySQL

There is also another attack to open a shell from the SQL Injection.

The source of the story can be found here.

תחרות התוכנות ל OpenMoko הראשונה

הסתיימה לה תחרות התכנות לOpenMoko הראשונה. בתחרות קיבלנו כמה תוכנות שהתפקיד שלהם הוא: לספק לנו נגני שירים ו podcast ל OpenMoko.

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

איזונים

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

אלו שמאמינים במדע, יצטטו את האמירה  (ניוטון ?) "לכל כוח יש תגובה הפוכה זהה", או באנגלית: "Every Action Has An Equal and Opposite Reaction".

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

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

tiOPF

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

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

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

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

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

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

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

עוד מקומות לתיעוד בנוסף לאתר של tiOPF ניתן למצוא כאן

שאלה לאנשי מוזילה

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

עם כמה תוספות Firefox מסוגל להתמודד בלי להגיע לבעייה כלשהי ?

יש סיבה לשאלה, אבל אודה לתשובה קודם ואח"כ אסביר את הסיבה.

תודה !

QA עצמי

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

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

הבעיה התקיימה בפונקציה register_file היות וכתבתי את הקוד בצורה הזו:

84   int length          = strlen(pathname) +1;
85   memset(file_rec->pathname, 0, FILENAME_MAX);
86   strncpy(file_rec->pathname, pathname, length);

כמו שאפשר לראות בשורה 86, בעוד ש file_rec->pathname הוא בגודל של FILENAME_MAX, , במקום לוודא שהאורך של pathname (פרמטר שאני מקבל בפונקציה) אינו גדול יותר מ FILENAME_MAX אני מניח שמישהו יבדוק את זה כשהוא מזין לי את אורך המחרוזת, ובכך אקבל אורך מחרוזת שהוא לא גדול מ FILENAME_MAX. כמובן שזו הנחה שגוייה, ולכן אם תשתמשו בAPI הזה ללא העתקה של מחרוזת באורך המתאים, יהיה ניתן לגרום לbuffer overflow אצלי בקוד.

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

84   int length          = strlen(pathname) +1;
85   if (length > FILENAME_MAX) /* Making sure not to have a buffer overflow !!! */
86   {
87     length = FILENAME_MAX;
88   }
89   memset(file_rec->pathname, 0, FILENAME_MAX);
90   strncpy(file_rec->pathname, pathname, length -1);

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

חשוב להבהיר שהקוד שלי לכשעצמו לא הכיל buffer overflow היות והשימוש בפונקציה התבצע בצורה הבאה:

206       char path[FILENAME_MAX];
207       memset(&path, 0, FILENAME_MAX);
208       strncpy(path, argv[counter], FILENAME_MAX - 1);
209       if (path_exists(path))
210       {
211         if (! register_file(list, path, FLAGS))

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

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

מי שלא מבין את דלפי…

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

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

אפשר לקחת את כח השפות השולטות כיום בשוק למשל: C, C++, ִJava, C#, Python, Ruby אנחנו יכולים לראות של C ו ++C כל הזמן מחפשים דרכים עוקפות ובגלל זה יש לנו את שאר הטנולוגיות שהזכרתי. אחד הדברים הכי בולטים בכל השפות האחרות, זה הניסיון לברוח מעודף הסימנים המורכבים והגישה העודף גמישה (אשר יוצרת רק בעיות) של C ו ++C תוך כדי ניסיון לשמור על תחביר קרוב כמה שניתן ל2 הטכנולוגיות הנפוצות כל כך.

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

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

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

דוגמא אחת (מני רבות): http://showmedo.com/videos/video?name=4010010&fromSeriesID=401

אפילו בלזרוס זה יותר פשוט מזה..