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

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

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

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

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