ארכיון חודשי: יוני 2011

עידן (אבטחת) המידע או "מידע רוצה להיות חופשי"

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

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

עבודה עם ActiveRecord בסינטרה

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

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

אז לאחרונה התבקשתי לבנות מערכת כזו, והיא לצערי גם חייבת לעבוד מול מסד נתונים (בחרתי את PostgreSQL, הרי לא הגיוני לבחור את MySQL לשום דבר, גם ככה היו לי מיליארד בעיות עם Foreign Key איתו כאשר כן ניסיתי לתכנן את המערכת, והוא לא אמין בשום צורה גם ככה במידע שהוא שומר), וכמובן שאלך על רובי וסינטרה לגודל כזה "גדול" של מערכת (2.5 מסכים), וכמובן במקום להשתמש בSQL נקי (עוד עושים את זה כיום ?), אני משתמש בORM, אשר לאחר בדיקה של 3 מהם ברובי, הגעתי להבנה כי ActiveRecord הוא הכי נורמאלי מכולם (למרות שגם לו יש הרבה חסרונות שגיליתי).

להמשיך לקרוא

בחירה שכלתנית

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

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

בעיה בגישה גרפית

בשנים האחרונות אנחנו רואים מהפכה בתחום הגישה הגרפית של תוכנות וסביבות עבודה בכלל. אם פעם היתה החשיבה של "לא נוגעים במה שכולם רגילים", הרי כיום (ב3-4 שנים האחרונות), אנחנו רואים כי הרבה מאוד סביבות גרפיות לעבודה השתנו לנו בלי הכיר בכלל.

אנחנו ראינו את KDE4 מוביל את המהפך, אח"כ Microsoft Vista הצטרף לחגיגה, ואחריו גם Microsoft Windows 7 נשאר בהוספת שינויים, וכיום אנחנו מוצאים אפילו את Gnome 3 עושה את אותה הטעות של האחרים ולשנות לגמרי את הממשק ללא התחשבות במשתמשים בו.

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

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

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

בעיות בהתנהגות החריגות (חלק רביעי)

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

ובכן יש מספר דברים שצריך להבין על חריגות ברובי:

  1. יצירת rescue "גלובלי", כלומר שנראה כי נבנה לתפוס כל חריגה אפשרית, ובכן הוא לא יתפוס כל חריגה אפשרית. כך שחריגות כמו NoMemoryError למשל, לא יתפסו ב rescue כללי.
  2. יש דרך ברובי "להעלים" חלק מהחריגות. כלומר למרות שחריגה מסויימת "הורמה", היא לא בהכרח "תעלה" לנו בשביל לטפל בה.
  3. התמודדות לא נכונה עם חריגה, יכולה להחביא את הבעיה האמיתית, ולהציג במקום בעיה אחרת לגמרי, ובכך איבדנו את הבעיה האמיתית שהרימה את החריגה.
  4. יש חריגות אשר למרות שאנחנו יכולים לתפוס אותם, אנחנו לא יכולים להציל את התוכנה מהן. יותר מזה, יש חריגות אשר יגרמו לתוכנית שלנו פשוט "למות" מייד בלי יכולת לטפל בשום דבר באמצע. חריגות כאלו מוגדרות כחריגות fatal, והן יתרחשו בד"כ כאשר ה core של רובי או משהו שקשור אליו אינו יכול להתמודד עם בעיה.
  5. יש מצבים בהם נרצה לחזור שוב על פעולות מסויימות (ראו את הפוסט שלי על "לחזור שנית" ברובי), וזה דורש מאיתנו החלטות על איך להתמודד עם הגישה הזו גם כן, אחרת הסעיף השני והשלישי יכנסו לתוקף (או אולי בעיה אחרת). גם באג בהתמודדות עם פעולות כמו redo ו retry יכולות לגרום לבעיות אחרות לגמרי, כדוגמת לולאה אין סופית.
  6. כאשר יש חריגה בThread (ארתיום, אני עונה על השאלה שלך), אז אם לא תפסנו אותה שם, היא תגיע לאב שהריץ את הThread בגלל שהThread "ימות" לנו, ואם האב לא יטפל בה, אז החריגה תגיע לאבא שלו וכו' עד שהיא תטופל או תגרום לתוכנה "למות".

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

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

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

עריכת הערך של Firebird בוויקיפדיה העברית

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

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

כמו כן, אם יש לכם הערות, הארות, יכולת לתרום לערך, מאוד אשמח שתעשו זאת גם אתם.

זריקת חריגה (חלק שלישי)

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

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

  • raise
  • fail

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

המתודות יכולות לקבל עד 3 פרמטרים (רק הפרמטר הראשון הוא חובה):

  1. מחלקה של החריגה שאותה רוצים "לזרוק"
  2. מחרוזת שרוצים להציג
  3. את ה stack שרוצים להציג, בשביל להראות מאיפה התרחשה החריגה

התחביר המינימאלי שנראה הוא כזה:

raise ArgumentError

ותחביר בשימוש מלא יראה בצורה הבאה: להמשיך לקרוא

תחביר של חריגה (חלק שני)

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

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

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