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

לפני כמה ימים חשבתי לשנות את תמונת הרקע בלינוקס. עכשיו אני ב i3 אז קפצתי ל arch wiki כדי למצוא איך משנים ב i3 תמונת רקע ולמדתי שם על תוכנה בשם feh שמגדירה wallpaper. ההוראות עבדו והצלחתי ליהנות מתמונת הרקע החדשה ... לשתי דקות בערך.

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

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

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

וכן CSS - אני מסתכל עליך...

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

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

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

שתי התוכניות הבאות עושות בדיוק את אותו דבר ונכתבו כדי לפתור את Advent Of Code 2019 Day 2. הראשונה:

mem = [1,9,10,3,2,3,11,0,99,30,40,50]

for i in range(0, len(mem), 4):
    if mem[i] == 1:
        mem[mem[i+3]] = mem[mem[i+1]] + mem[mem[i+2]]
    elif mem[i] == 2:
        mem[mem[i+3]] = mem[mem[i+1]] * mem[mem[i+2]]
    elif mem[i] == 99:
        break
    else:
        raise Exception(f"Invalid cmd #{mem[i]}")

print(mem[0])

וחברתה הארוכה יותר:

from more_itertools import sliced

memory = [1,9,10,3,2,3,11,0,99,30,40,50]

for [opcode,
     input_index_1,
     input_index_2,
     output_index
    ] in sliced(memory, 4):
    if opcode == 1:
        memory[output_index] = memory[input_index_1] + memory[input_index_2]
    elif opcode == 2:
        memory[output_index] = memory[input_index_1] * memory[input_index_2]
    elif opcode == 99:
        break
    else:
        raise Exception(f"Invalid cmd #{memory[i]}")

print(memory[0])

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

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

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

ב 90% מהאתגרים התכנותיים שתתמודדו איתם (אפילו יותר בניקוי ראיונות עבודה) זאת לא התשובה שחשובה אלא הדרך. ו 90% מהאנשים יודעים את זה ועדיין מחפשים את התשובה.

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

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

לקח לי הרבה זמן לעבור מ RabbitMQ ל Kafka, בעיקר בגלל הארנב. ל ZeroMQ לא היה סיכוי.

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

ספק ה VPN האהוב עליי הוא TunnelBear (וכן זה בגלל הדוב) ובעבודה עם בסיסי נתונים אין תחרות ל DBeaver (בגלל הבונה) ובדיקות אוטומטיות אני כותב ב Capybara (נו, בגלל הקפיברה)

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

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

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

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

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

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

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

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

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

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

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

הפקודה read_csv של פנדס היא מופלאה. רוב קבצי ה CSV שאנחנו מוצאים בדוגמאות באינטרנט כתובים בקידוד UTF8 וזה בדיוק גם קידוד ברירת המחדל של read_csv.

אבל כשעוברים ממשחקים לעולם האמיתי אנחנו מוצאים קבצי CSV פחות נחמדים: החל מקבצים ישנים שמקודדים ב Extended ASCII או במקרה העוד יותר גרוע קבצים שמערבבים תווים בכל מיני קידודים.

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

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

>> pd.read_csv('053cea08-09bc-40ec-8f7a-156f0677aff3.csv', '|')

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xee in position 0: invalid continuation byte

עד לפה לא מבהיל מדי כי תמיד אפשר להעביר Encoding לפנדס. אבל הפעם גם זה לא עבד:

>> pd.read_csv('053cea08-09bc-40ec-8f7a-156f0677aff3.csv', encoding='iso8859-8')

UnicodeDecodeError: 'charmap' codec can't decode byte 0xd2 in position 127430: character maps to <undefined>

מה עושים? תשמחו לשמוע שיש פיתרון יחסית פשוט: נפתח את הקובץ עם הקידוד שאנחנו רוצים ונבקש מ open שתחליף תווים שלא תואמים לקידוד בסימני שאלה. את ה File Handle נעביר לפנדס שישמח לקבל את המידע אחרי פיענוח. הקוד כולו נראה כך:

>> fd = open('053cea08-09bc-40ec-8f7a-156f0677aff3.csv', encoding='iso8859-8', errors='replace')
>> df = pd.read_csv(fd, '|')

עכשיו אפשר להינות מהמידע שהצלחנו לקרוא למשל מי יצרנית הרכב הפופולרית בישראל:

df.groupby('tozeret_nm').size().sort_values(ascending=False)

tozeret_nm
מזדה יפן         299175
יונדאי קוריאה    228002
קיה קוריאה       205592
טויוטה יפן       189340
סקודה צ'כיה      173473