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

הפקודה MERGE ב neo4j יוצרת צמתים חדשים וקשתות חדשות אבל בצורה מעניינת - במקום שנגיד לה מה אנחנו רוצים ליצור אנחנו מתארים לה את מצב העניינים אחרי היצירה. אם הכל כבר קיים merge לא תעשה כלום, ואם החיבור לא קיים היא תיצור אותו.

איפה הבעיה?

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

ניקח דוגמה מבסיס הנתונים של הסרטים מארגז החול של neo4j. בסיס הנתונים מכיל Person בשם Jack Nicholson ו Person נוסף בשם Al Pacino. אני רוצה לחבר בין שניהם בקשר שנקרא FRIEND אז אני מריץ:

MERGE (n:Person{name:"Jack Nicholson"})-[:FRIENDS]-(m:Person{name:"Al Pacino"}) RETURN n LIMIT 25

אבל במקום ליצור את הקשר אני מקבל שגיאה:

Node(17) already exists with label `Person` and property `name` = 'Jack Nicholson'

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

הפיתרון, מעבר להבנת החשיבות של אינדקסים, הוא לחלק את ה MERGE לפקודות MATCH כשרוצים להשתמש במידע קיים, כלומר השאילתה תהיה:

MATCH (n:Person{name:"Jack Nicholson"})
MATCH (m:Person{name:"Al Pacino"})
MERGE (n)-[:FRIENDS]-(m) RETURN n LIMIT 25

בזמן ריענון מצגת על פייתון וביצוע תהליכים במקביל הרצתי את התוכנית של ה Threads שמראה למה צריך לסנכרן גישה למשתנים למרות ה GIL:

import threading

i = 0

def test():
    global i
    for x in range(100000):
        i += 1

threads = [threading.Thread(target=test) for t in range(10)]
for t in threads:
    t.start()

for t in threads:
    t.join()

print(i)
assert i == 1000000, i

אבל במקום להתרסק ב assert הכל עבר בשלום.

לא עזר להריץ שוב. ושוב. ושוב.

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

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

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

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

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

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

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

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

כשהדבר הגדול הבא דופק על הדלת, אל תשאירו אותו בחוץ.

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

כן טוב, מה שהיה הוא לא מה שיהיה. כרום 37, אדג' 79, פיירפוקס 98, אופרה 24, ספארי 15.4 ואפילו דפדפני המובייל - כולם תומכים היום תמיכה מובנית וטבעית באלמנט dialog ויודעים להציג דיאלוג מודאלי בלי שום ספריה ובצורה נגישה.

בואו נראה איך זה עובד.

משמעות ראשי התיבות WEI היא Web Environment Integrity. זהו API שנתמך כבר בכרום אבל עדיין לא סטנדרטי שמטרתו לוודא בצד השרת שהדפדפן שפונה לקבל את התוכן הוא דפדפן "אותנטי".

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

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

אלה הפחדים המרכזיים של מפתחים והקהילה מ API זה:

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

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

3. פרטיות - איך השרת של גוגל ידע אם אתה בן אדם שגולש דרך דפדפן אמיתי? האם נתוני שימוש או נתונים התנהגותיים כלשהם ישודרו מהדפדפן לשרת האימות? האם תהיה לנו שליטה על הנתונים שנשלחים?

4. תוספים לדפדפן - האם תוספים לדפדפן יוכלו למשוך מידע מאתרים? או לחסום מידע מאתרים? איך כל העסק ישפיע על עולם פיתוח התוספים?

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

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

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

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

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

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

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

ניקח דוגמה לבדיקה פשוטה כאן מהאתר:

test 'should subscribe to blog mailing list' do
  visit blog_index_url
  fill_in :email, with: @email
  click_button I18n.t('sign_up_email')

  assert_selector 'p', text: I18n.t('subscriptions.success')
  assert Subscriber.exists?(email: @email)
end

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

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

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

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

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

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

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

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

3. בסקר של אקליפס מ 2009, חמשים ושמונה אחוז מהמשיבים השתמשו עדיין ב SVN. ב 2011 גיטהאב עקף בפופולריות את SourceForge ושם התחיל אפקט כדור השלג. ב 2015 גיט עדיין עמד על 69% נתח שוק, מספר שהפך ב 2018 ל 87% כשמייקרוסופט רכשה את גיטהאב והכניסה את גיט גם לארגונים גדולים.

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

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

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

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

אני מזהה את התבנית הזאת ומאיזה ספר היא הגיעה.

אני רואה את ה Design Pattern שלא ממומש בדיוק לפי הספר אבל גם ברור למה.

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

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

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