הבלוג של ינון פרק

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

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

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

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

הבאג שנחשף אתמול ב 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. אין בדיקה שמצבים חיצוניים מסוימים יובילו לכישלון ביצירת משתמש, למשל אין בדיקה שאם יש כבר משתמש עם כזה אימייל במערכת אז אי אפשר יהיה ליצור אותו.

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

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

כשאני כותב פונקציה של 200 שורות.

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

כשאני כותב קוד שאין לי איך לבדוק אותו.

כשאני שומר את המפתח בתוך הקוד.

כשאני מוותר על כתיבת טיפוסי משתנים או תיעוד.

כשאני מעתיק קטע קוד מ Chat GPT או Stack Overflow, בלי להבין אותו עד הסוף.

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

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

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

נתבונן בתוכנית הבאה בפייתון שמחשבת את ה sh256 של הקובץ /etc/passwd:

import hashlib
from pathlib import Path

data = Path("/etc/passwd").read_text().encode("utf8")
print(hashlib.sha256(data).hexdigest())

וכן העובדה שהקוד עובד רק מחמירה את המצב.

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

אז איך מגיעים לכתוב קוד כזה? נו זה קל, מתחילים עם:

import hashlib
from pathlib import Path

data = Path("/etc/passwd").read_text()
print(hashlib.sha256(data).hexdigest())

מקבלים את הודעת השגיאה:

TypeError: Strings must be encoded before hashing

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

import hashlib
from pathlib import Path

data = Path("/etc/passwd").read_bytes()
print(hashlib.sha256(data).hexdigest())

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

import hashlib
from pathlib import Path

file_path = "/etc/passwd"

try:
    with open(file_path, 'rb') as file:
        file_content = file.read()
        hash_value = hashlib.sha256(file_content).hexdigest()
        print(f"SHA-256 Hash of '{file_path}': {hash_value}")
except FileNotFoundError:
    print(f"Error: File '{file_path}' not found.")
except PermissionError:
    print(f"Error: Permission denied while trying to read '{file_path}'.")
except Exception as e:
    print(f"Error: {e}")

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

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

"מהו דבר אחד שהיית משנה ב X"

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

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

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

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

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

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

מצטט מSoatok כי העצה מושלמת, תרגום שלי:

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

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

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

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

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

הבעיה עם פחד בתור מנטור היא שאנחנו פוחדים מהדברים הלא נכונים, לדוגמה-

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

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

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

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

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

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