ToCode

# לא Java, מחרוזת וביטוי רגולארי זה שני דברים שונים ל Java יש API לעבודה עם ביטויים רגולאריים דרך החבילה java.util.Pattern. עם החבילה הזאת אפשר לכתוב דברים כמו:

Pattern p = Pattern.compile("a*b");
Matcher m = p.matcher("aaaaab");
boolean b = m.matches();

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

boolean b = Pattern.matches("a*b", "aaaaab");

וביום רגיל היינו עוצרים פה את השיחה על ביטויים רגולאריים וחוזרים לדבר על קוד. אבל עם Java שום יום אינו יום רגיל. מחוץ לחבילת הביטויים הרגולאריים יש חבילה של מחרוזות ובה הפונקציה split:

public String[] split(String regex)

וכן שם הפרמטר נבחר בכוונה - ג'אווה מתיחס למחרוזת ההפרדה ל split כמו ביטוי רגולארי. קוד? בטח. הנה שתי דוגמאות:

import java.util.Arrays;

class Main {
  public static void main(String[] args) {
    // prints: [hello, world]
    System.out.println(Arrays.toString("hello-world".split("-")));

    // prints: []
    System.out.println(Arrays.toString("hello.world".split(".")));
  }
}

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

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

(let [agent (ssh-agent {})]
  (let [session (session agent "host-ip" {:strict-host-key-checking :no})]
    (with-connection session
      (let [channel (ssh-sftp session)]
        (with-channel-connection channel
          (sftp channel {} :cd "/remote/path")
          (sftp channel {} :put "/some/file" "filename"))))))

בבלוק מעתיקים קבצים לשרת ואנחנו רואים שצריך להעביר את המשתנה channel כל פעם שקוראים ל sftp. זה הגיוני כי אנחנו בשפה פונקציונאלית והסטייט נשמר מחוץ לפונקציות, אבל יכול להיות מעייף בכתיבה. סקאלה, שמהתרשמותי עד כה מנסה להיות שפה פונקציונאלית ידידותית גם אנשים שאינם פונקציונאליים, כוללת מנגנון מעניין כדי לחסוך כפילויות מסוג זה, מנגנון שנקרא given / using. למעשה מנגנון ה given וה using של סקאלה הרבה יותר מתוחכם ממה שאני מראה פה, אבל המקרה פה בפוסט הוא דוגמה לשימוש אחד יחסית קל להבנה במנגנון זה. איך זה עובד? בהגדרת פונקציות בסקאלה אנחנו יכולים להגדיר בנוסף לפרמטרים הרגילים שעוברים לפונקציה גם משתני "קונטקסט". הדרך הכי קלה לחשוב עליהם היא בתור "משתני סביבה" של הבלוק הספציפי בתוכנית. לדוגמה כך נראית הגדרה של פונקציה המקבלת מידע על שרת בפרמטר בשם config:

def readUsers(config: ServerConfig): Unit =
  println(s"read users from ${config.ip}")

וכך נראית אותה פונקציה כשהפרמטר הזה יכול לעבור בתור "משתנה סביבה":

def readUsers(using config: ServerConfig): Unit =
  println(s"read users from ${config.ip}")

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

@main def main(): Unit =
  given config: ServerConfig(ip = "12.13.14.15", port = 8080)
  readUsers

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

def readUsers(using config: ServerConfig): Unit =
  println(s"read users from ${config.ip}")

def addUser(username: String, password: String)(using config: ServerConfig): Unit =
  println(s"add user ${username} to ${config.ip}")

def wrapper(using ServerConfig): Unit =
  readUsers

@main def main(): Unit =
  given config: ServerConfig(ip = "12.13.14.15", port = 8080)

  readUsers
  addUser("foo", "bar")
  wrapper

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

(def ^:dynamic *config* {:ip "default-ip"})

(defn read-users []
  (println (str "read users from " (:ip *config*))))

;; Usage
(let [custom-config {:ip "custom-ip"}]
  (binding [*config* custom-config]
    (read-users)))

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

# האם מפתחים חייבים להפיץ תוכנות מאובטחות? האיזון בין חובת המפתחים להפצת תוכנות מאובטחות לבין חופש של מפתחים לכתוב ולהפיץ תוכנות ללא דאגות נמצא בימים אלה בדיונים סופיים בפרלמנט האירופי, שכבר עובד על הצעה שנמצאת בשלבים סופיים של אישורים בשם Cyber Resilience Act. מטרת ההצעה היא להבהיר למפתחים ולמשתמשים מי אחראי לתיקון בעיות אבטחה ובדיוק באיזה אופן. ## האתגר היום הבעיה ש CRA מנסה לפתור בקצרה היא בעיית שרשרת האספקה - יש לנו תוכנה שתלויה בתוכנות אחרות, אבל אף אחד לא אחראי על האבטחה של אותן תוכנות אחרות וכשיש באג לוקח הרבה זמן לתקן ולפעמים גם לדווח. מקרה גדול ומפורסם שהתחיל הרבה מהשיחות האלה היה הפריצה ל Solar Winds, פריצה שגרמה לחברה להפיץ "עדכון" ללקוחות כאשר העדכון היה בעצם דלת אחורית לפריצה, והלקוחות היו חברות ענק כולל ממשלת ארצות הברית. הרכיב הפרוץ היה באוויר בין מרץ ליוני 2020, אבל יותר מעניינת היא העובדה שבשביל להשתיל אותו ההאקרים (ככל הנראה רוסים) פרצו ל Solar Winds ושינו את תהליך בניית הקוד שלהם. המטרה של האיחוד האירופי היא למנוע מתקפות מסוג זה ורבות נוספות באמצעות חיוב חברות לבצע תהליכי בדיקות אבטחה באופן תדיר, וחיוב זה ממשיך לכל אורך שרשרת האספקה של כל תוכנה. ## האתגר שמציבה CRA עבור מתכנתי קוד פתוח אומנם שיפור אבטחת מידע של מוצרים הוא מטרה ראויה אבל השטן הוא בפרטים ומפתחי קוד פתוח רבים מתלוננים על הדרך. בפרט: 1. בטיוטות העדכניות ביותר ה CRA חל על חברות מסחריות שמרוויחות ממוצרי קוד פתוח שהן מתחזקות. זה אומר שאם אני פותח חברה שמפיצה ספריית תוכנה ומוכר שירותי ייעוץ על ספריה זו אני עשוי להיות מחויב לעמוד בסטנדרטים של האיחוד האירופי. 2. ה CRA מחייב דיווח על בעיות אבטחה תוך מספר שעות מרגע גילוי הפרצות. מנגנון כזה לא יאפשר למתכנתי קוד פתוח להפיץ בצורה מסודרת עדכוני תוכנה שמתקנים את הפירצה בזמן, כי מפתחי קוד פתוח לא יודעים מי כל הלקוחות שלהם ואין להם דרך להגיע לכל הלקוחות בזמן סביר. 3. ה CRA מוסיף נטל רגולטורי בדמות בדיקות אבטחה שמפתחים חייבים לבצע, ולפעמים אף בדיקות חיצוניות (תלוי במוצר). לחברות קוד פתוח שממילא חיות על תרומות נטל כזה עלול להיות הוצאה אחת יותר מדי. סך הכל כמו בהרבה סיטואציות שמעלים את הרף יש פה בעייה של איזון בין כמה קל לעסקים קטנים או חדשים להיכנס ולפעול בשוק לעומת איכות המוצרים והרווח לכלל האוכלוסיה. עדיין מוקדם לדעת איך דברים הולכים להתפתח והאם שינוי זה יביא לשיפור אבטחת המידע של מוצרי תוכנה באופן כללי, אבל אני באופן אישי לא אופטימי. הבעיה עם אבטחת מידע היא שעל כל חור שנסגר נפתחים עוד 5, ולא לגמרי ברור באיזו מידע תוספת הבדיקות או חובת הדיווח ישפרו את המצב.

# מה כותבים קודם - ממשק משתמש או לוגיקה? לכל אופציה יש את היתרונות והחסרונות שלה, ולפעמים התשובה מורכבת. לכתוב את ממשק המשתמש לפני הלוגיקה אומר שאני מכניס נתונים פיקטיביים, קבועים, למערכת, או בונה לוגיקה מאוד בסיסית רק כדי שאוכל להתקדם. ברגע שיש משהו על המסך אני יכול "לשחק" עם הממשק וחווית המשתמש עד שאני מגיע למשהו שעובד, ותוך כדי תנועה אני מעדכן את הלוגיקה ולאט לאט עובר לנתונים אמיתיים. לכתוב את הלוגיקה לפני ממשק המשתמש אומר שאני משקיע המון עבודה מראש בכתיבת סכימות לבסיסי נתונים, שאילתות, קוד צד שרת ובדיקות עליו ורק אחרי ששכבת המידע בנויה אני ממשיך לבנות את ממשק המשתמש. את שכבת המידע בדקתי עם תוכניות בדיקה קטנות או בדיקות יחידה כדי שלא יהיו הפתעות כשאגיע לכתוב את ה GUI. היתרונות של כתיבת ממשק המשתמש קודם הם לכן: 1. אני לא כותב לוגיקה מיותרת אלא רק את המנגנונים שהמוצר והמשתמשים שלו צריכים. 2. אני יכול לארגן את שכבת הלוגיקה כדי שממשק המשתמש יהיה קל לפיתוח, ויכול לבנות על זה שיש לי תמיד את הנתונים שאני צריך. 3. אני מגיע יחסית מהר ללקוחות או למנהלים עם מוצר שהם יכולים לראות, מה שמאפשר לי לקבל פידבק בשלב מוקדם של התהליך. אבל זה לא כל הסיפור. היתרונות של פיתוח שכבת המידע קודם הם: 1. מימוש שכבת מידע יציבה עם בדיקות מבטיח שיהיו לי פחות באגים בשכבת המידע או לפחות שיהיה קל יותר למצוא ולתקן אותם. 2. אחרי שיש ממשק משתמש ופידבק עליו, אנחנו מבלים המון זמן בהתאמת המוצר לפידבק מהלקוחות (בצדק) ולא מספיק זמן בבניית שכבת מידע יציבה. 3. אילוצים שהגיעו מממשק המשתמש עלולים לגרום לנו לשמור מידע בצורה לא יעילה או מידע כפול, וכשנבין שאנחנו רוצים לשנות את מבנה הטבלאות זה כבר יהיה מאוחר מדי. 4. הרבה יותר קל לשנות ממשק משתמש כשיש שכבת מידע יציבה מאשר לשנות שכבת מידע כשיש ממשק משתמש יציב. קצת כמו עם TDD אני חושב שהבעיה המרכזית בפיתוח ממשק משתמש קודם היא שאחרי שיש ממשק ומוצר קשה "לחזור אחורה" כדי לכתוב את הלוגיקה כמו שצריך, ואז אנחנו תקועים עם מבנה טבלאות לא אופטימלי שמאט אותנו במימוש פיצ'רים חדשים. פיתרון טוב וקשה לביצוע יהיה לחלק את הפיתוח לשלבים. בשלב הראשון נבנה ממשק משתמש עם שכבת מידע מנוונת רק בשביל להבין את דרישות הפרויקט, ובשלב השני אחרי שיש משהו באוויר נחזור לשולחן השרטוטים ונבנה מחדש את שכבת המידע מאפס בצורה יציבה יותר שלוקחת בחשבון את כל הפיצ'רים שאנחנו עכשיו יודעים שצריכים ומנגנוני ריפקטורינג ובדיקות שיעזרו לנו להמשיך ולתקן תוך כדי תנועה. וכן זה מדכא כי אי אפשר באמת לבנות מחדש רק את שכבת המידע בלי לגעת בקוד הממשק ולכן תהליך כזה הוא כמעט כתיבה מחדש של הפרויקט בפעם השניה.

# בואו נסדר טקסט בטבלה עם הפקודה column הפקודה column נועדה כדי לקבל טקסט ארוך ולשבור אותו לעמודות כדי שיהיה קל יותר לקרוא אותו בלי לגלול, כמו טורים בדף של עיתון. אפשר לראות דוגמה קלה לשימוש בה כשנעביר אליה תוכן של קובץ. כך נראה הקובץ /etc/shells אצלי:

$ cat /etc/shells

# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/bash
/bin/csh
/bin/dash
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
/usr/local/bin/pwsh

וכך זה נראה עם column:

$ cat /etc/shells | column

# List of acceptable shells for chpass(1).                      /bin/csh                                                        /bin/tcsh
# Ftpd will not allow users to connect who are not using        /bin/dash                                                       /bin/zsh
# one of these shells.                                          /bin/ksh                                                        /usr/local/bin/pwsh
/bin/bash                                                       /bin/sh

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

#!/bin/bash

end=${1:-10}

for ((i=1; i <= $end; i++))
do
  for ((j=1; j <= $end; j++))
  do
    printf "%d " $((i * j))
  done
  echo
done

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

1 2 3 4 5 6 7 8 9 10
2 4 6 8 10 12 14 16 18 20
3 6 9 12 15 18 21 24 27 30
4 8 12 16 20 24 28 32 36 40
5 10 15 20 25 30 35 40 45 50
6 12 18 24 30 36 42 48 54 60
7 14 21 28 35 42 49 56 63 70
8 16 24 32 40 48 56 64 72 80
9 18 27 36 45 54 63 72 81 90
10 20 30 40 50 60 70 80 90 100

התוספת של column -t כבר עושה את הקסם:

$ bash table.bash | column -t

1   2   3   4   5   6   7   8   9   10
2   4   6   8   10  12  14  16  18  20
3   6   9   12  15  18  21  24  27  30
4   8   12  16  20  24  28  32  36  40
5   10  15  20  25  30  35  40  45  50
6   12  18  24  30  36  42  48  54  60
7   14  21  28  35  42  49  56  63  70
8   16  24  32  40  48  56  64  72  80
9   18  27  36  45  54  63  72  81  90
10  20  30  40  50  60  70  80  90  100

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

ubuntu@primary:~/Home/tmp/blog$ bash table.bash |column -t -R0
 1   2   3   4   5   6   7   8   9   10
 2   4   6   8  10  12  14  16  18   20
 3   6   9  12  15  18  21  24  27   30
 4   8  12  16  20  24  28  32  36   40
 5  10  15  20  25  30  35  40  45   50
 6  12  18  24  30  36  42  48  54   60
 7  14  21  28  35  42  49  56  63   70
 8  16  24  32  40  48  56  64  72   80
 9  18  27  36  45  54  63  72  81   90
10  20  30  40  50  60  70  80  90  100

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

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

# תזכורת מ curl - מי ביקש ממך? הבאג שנחשף אתמול ב libcurl הוא כזה שמתכנתים אוהבים לעשות ואוהבים להתחרט עליו. היוצר של curl דניאל סטנברג פרסם את הפרטים. בגדול כשמושכים דף דרך libcurl אפשר להשתמש בפרוקסי, ואם משתמשים בפרוקסי אפשר לבחור לפענח לבד את שם השרת אליו פונים ולתת לפרוקסי את כתובת ה IP, או להעביר את שם השרת לפרוקסי שהוא ישבור את הראש. יש לו גם משתנה בשם socks_proxy.proxytype שיכול לקבל את הערך CURLPROXY_SOCKS5 בשביל לפענח לבד את כתובת ה IP אליה צריך להתחבר, או את הערך CURLPROXY_SOCKS5_HOSTNAME בשביל להעביר את שם השרת ישירות לפרוקסי שהוא כבר ישבור את הראש. אבל במצב שצריך להעביר את שם השרת יש בעיה - שרתי socks תומכים רק בשמות שרת באורך עד 255 תווים. עכשיו מה הייתם עושים אם משתמש בחר בשיטת עבודה לחיבור "שלח את שם השרת לפרוקסי" אבל שם השרת שהוא מנסה להתחבר אליו יצא ארוך יותר ממה שמתאפשר לשלוח? דניאל עשה מה שרבים מאיתנו היו עושים ומתחרטים עליו בדיעבד - ברגע שהוא ראה שם שרת ארוך הוא הניח שמישהו העביר בטעות את הערך הלא נכון לפרמטר שבוחר מצב עבודה, ושינה את מצב העבודה לפיענוח שם שרת מקומי. הבעיה שבגלל מבנה הקוד, השינוי לא משפיע על כל המצבים ואפשר לעקוף אותו. תוקף זדוני שרוצה להפיל את ה curl שלכם יכול לבנות שרת שישלח Redirect עם שם שרת ארוך מדי ובמצבים מסוימים יעקוף את שינוי מצב העבודה ויגרום ל Heap Overflow בקוד הלקוח. הקוד הפגיע בגדול הוא:

  bool socks5_resolve_local =
    (conn->socks_proxy.proxytype == CURLPROXY_SOCKS5) ? TRUE : FALSE;
  const size_t hostname_len = strlen(sx->hostname);
  ssize_t len = 0;
  const unsigned char auth = data->set.socks5auth;
  bool allow_gssapi = FALSE;
  struct Curl_dns_entry *dns = NULL;

  DEBUGASSERT(auth & (CURLAUTH_BASIC | CURLAUTH_GSSAPI));
  switch(sx->state) {
  case CONNECT_SOCKS_INIT:
    if(conn->bits.httpproxy)
      infof(data, "SOCKS5: connecting to HTTP proxy %s port %d",
            sx->hostname, sx->remote_port);

    /* RFC1928 chapter 5 specifies max 255 chars for domain name in packet */
    if(!socks5_resolve_local && hostname_len > 255) {
      infof(data, "SOCKS5: server resolving disabled for hostnames of "
            "length > 255 [actual len=%zu]", hostname_len);
      socks5_resolve_local = TRUE;
    }

וזה פגיע כי שינוי הערך של המשתנה הבוליאני קורה רק במקרה של CONNECT_SOCKS_INIT, אבל אפשר להיכנס לפונקציה הזאת גם ישירות ל case-ים אחרים במצבים של שרת פרוקסי איטי. המסקנה של דניאל נכונה גם לגבינו ולכל קוד שאנחנו כותבים. הוא כותב: > curl should not switch mode from remote resolve to local resolve due to too long host name. It should rather return an error and starting in curl 8.4.0, it does. החלפת מצב הפעולה רק בגלל שגילינו ב init ששם השרת ארוך מדי היתה הטעות, כי משתמשים שביקשו מצב פעולה מסוים לא ציפו להתנהגות זו. זריקת שגיאה במקרה כזה היתה נותנת למשתמשים אפשרות לבחון טוב יותר את ה use case ולבחור את מצב הפעולה הטוב ביותר עבורם.

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

MATCH (tom:Person {name:'Tom Hanks'})-[rel:DIRECTED]-(movie:Movie)
RETURN tom.name, tom.born, movie.title, movie.released

כדי להחזיר את כל הסרטים בהם שיחק טום הנקס בלי להתחייב על כיוון הקשת DIRECTED, או את:

MATCH (:Person {name: 'Tom Hanks'})-[:DIRECTED]->(movie:Movie)
RETURN movie.title

שתופסת רק את הסרטים כשכיוון הקשת הוא מהשחקן לסרט. בגרמלין אם יש לי בגרף צומת מסוג person בשם marko וממנו יוצאת קשת בשם created לצומת שמייצג פרויקט שמרקו יצר אז השאילתה:

g.V().has('person','name','marko').out('created')

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

g.V().has('person','name','marko').both('created')

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

# מה בעצם בדקת שם? נתבונן בקוד הבדיקה הבא מתוך leantime:

    #[Depends('Tests\Acceptance\LoginCest:loginSuccessfully')]
    public function createAUser(AcceptanceTester $I)
    {
        $I->wantTo('Create a user');
        $I->amOnPage('/users/showAll');
        $I->click('Add User');
        $I->waitForElement('#firstname', 120);
        $I->fillField('#firstname', 'John');
        $I->fillField('#lastname', 'Doe');
        $I->selectOption('#role', 'Read Only');
        $I->selectOption('#client', 'Not assigned to a client');
        $I->fillField('#user', 'john@doe.com');
        $I->fillField('#phone', '1234567890');
        $I->fillField('#jobTitle', 'Testing');
        $I->fillField('#jobLevel', 'Testing');
        $I->fillField('#department', 'Testing');
        $I->click('Invite User');
        echo $I->grabPageSource();
        $I->waitForElement('.growl', 120);
        $I->wait(2);
        $I

עזבו את הפרטים, זה php אולי לא מכירים ולא כזה חשוב. יותר מעניין מה העלות ומה התועלת שיש לנו כאן. הבדיקה מנסה ליצור משתמש ומחכה לראות על המסך הודעה שהמשתמש נוצר. בנוסף, באותו קובץ אין בדיקות נוספות ליצירת משתמש, כך שאני מניח שמישהו סומך על הבדיקה הזאת. עכשיו בואו נראה מה הבדיקה מוודאת, ואיך היינו יכולים לגשת לזה אחרת: 1. הבדיקה מוודאת שאפשר למלא פרטים בטופס ואין וולידציית צד-לקוח שמונעת ממני להגיש אותו. 2. הבדיקה מוודאת שיש ב HTML אלמנטים של טופס עם המזהים שמופיעים בקוד הבדיקה. 3. הבדיקה מוודאת שבדף שחוזר מהטופס יש הודעה שאומרת שמשתמש נוצר בהצלחה. 4. הבדיקה מוודאת שהטופס מוגש כשניגשים ל URL שמופיע בקוד הבדיקה. וכן יש גם הרבה דברים שהבדיקה לא מוודאת ואולי היה לנו מעניין לוודא אותם: 1. אין בדיקה שמשתמש אכן נוצר בבסיס הנתונים. 2. אין בדיקה שפרטי המשתמש שנוצר קשורים לפרטים שהוזנו בטופס. 3. אין בדיקה שפרטים מסוימים יובילו לכישלון ביצירת משתמש, ובאיזה מצבים. 4. אין בדיקה שמצבים חיצוניים מסוימים יובילו לכישלון ביצירת משתמש, למשל אין בדיקה שאם יש כבר משתמש עם כזה אימייל במערכת אז אי אפשר יהיה ליצור אותו. רשימה כזאת היא הצעד הראשון בדרך להפוך בדיקה קיימת לאפקטיבית יותר. אחרי זה אפשר להחליט מה אנחנו בעצם רוצים לבדוק - האם זו בדיקת אינטגרציה שצריכה לוודא שכל המערכת עובדת בתיאום? אם כן צריך לוודא שהמשתמשים אכן נכנסו לבסיס הנתונים ולהוסיף עוד בדיקות על המצבים השונים של הצלחה וכישלון ביצירת המשתמשים. או שאולי זו בדיקת יחידה שצריכה לוודא שהטופס מוגש ומכיל את האלמנטים המתאימים? אם זה המצב כדאי להפריד אותה לבדיקות קטנות יותר, כל בדיקה תכיל אלמנט ספציפי כדי שכישלון בבדיקה יוכל להפנות אותי מיד לזיהוי התקלה. השקעה בבדיקות היא מחויבות. לוקח זמן לכתוב את הבדיקה ואחרי זה לוקח זמן לתחזק אותה, כי היא יכולה להיכשל בכל שינוי. כשהבדיקות לא מספיק אפקטיביות אנחנו רק מבזבזים זמן ויוצרים תסכול. אם כבר החלטתם לכתוב בדיקות, עשו לעצמכם טובה והשקיעו את המאמץ בכתיבת בדיקות יעילות, והשאירו בקוד רק בדיקות שמביאות ערך אמיתי.