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

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

ככל שהתקדמתי שורה ועוד שורה חשבתי -

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

״חייבת להיות ספריה שעושה את זה... אני לא מאמין שאני מבזבז ככה את הזמן״

״יו אני בטח מפספס פה מלא מקרי קצה, בחיים לא אצליח לתפוס ולתקן את כולם״

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

״עוד פעם if ??? זה כבר החמישי שלי בפונקציה. למה כל כך הרבה דברים יכולים להשתבש!?״

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

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

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

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

1. מובאקס בעשר דקות

2. איך לנהל State גלובאלי של יישום ריאקט עם MobX

3. וובינר מבוא למובאקס

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

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

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

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

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

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

1. כל פעם שמעלים גירסה יש כמה שניות של Down Time בהן המערכת לא זמינה.

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

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

4. יש כמה בדיקות שמדי פעם נכשלות בלי שאף אחד יודע למה.

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

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

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

הפונקציות atob ו btoa של JavaScript משמשות להמרה של מחרוזות ל Base64 ובחזרה. מכל מיני אילוצים טכניים מאפייני שפת JavaScript החליטו שהן יעבדו טוב רק על מחרוזות ASCII כלומר מחרוזות באנגלית בלבד. אז אני יכול לכתוב:

> btoa("ninja")
'bmluamE='

אבל לא יכול לכתוב:

> btoa('תפוז')
Uncaught:
DOMException [InvalidCharacterError]: Invalid character
    at new DOMException (node:internal/per_context/domexception:70:5)
    at __node_internal_ (node:internal/util:497:10)
    at btoa (node:buffer:1229:13)

לכן ה Best Practice בשביל להשתמש בפונקציות אלה הוא להשתמש בעוד המרה לפני הפעלתן. כך מהתיעוד:

function utf8_to_b64( str ) {
  return window.btoa(unescape(encodeURIComponent( str )));
}

function b64_to_utf8( str ) {
  return decodeURIComponent(escape(window.atob( str )));
}

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

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

גירסה 18 של נוד מביאה איתה לא מעט חידושים: התמיכה ב ES Modules השתפרה פלאים, הוסיפו מודול מובנה להרצת בדיקות יחידה, ונוספה תמיכה לשני ממשקי רשת מהדפדפן שהם Fetch API ו Web Streams API.

בפוסט זה אציג את השימוש ב Fetch API ב Node.

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

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

לא להאמין שהעברתי חיים שלמים בלי לדעת את זה, אבל אם גם אתם פתאום לא בטוחים אז הגעתם למקום הנכון. קודם כל משמעות ראשי התיבות דומה - URL הוא Uniform Resource Locator ו URI הוא Uniform Resource Identifier. ההבדל ביניהם הוא עדין אבל חשוב:

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

https://schema.org/Person
foo://example.com:8042/over/there?name=ferret#nose
urn:oasis:names:specification:docbook:dtd:xml:4.1.2
urn:isbn:0-486-27557-4
https://stackoverflow.com/questions/4913343/what-is-the-difference-between-uri-url-and-urn
data:,Hello%20World

חלק מה URI-ים מתיחסים למסמך ספציפי ברשת ומסבירים איך להגיע אליו. למשל ה URI הזה:

https://stackoverflow.com/questions/4913343/what-is-the-difference-between-uri-url-and-urn

הוא קישור ל Stack Overflow. הוא סוג של "מצביע" לדף בפרוטוקול https. מזהים כאלה נקראים URL-ים, כי הם מספקים דרך לאתר (to locate) את המשאב שהם מזהים. הרבה פעמים, וזה קצת מבלבל, ה URI יהיה בעצם כתובת אינטרנט של דף שלא באמת קשור לדבר שהוא מזהה. לדוגמה ב HTML 4 מסמך היה מתחיל בשורה:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">

אבל לדפדפנים לא היה אכפת אם הייתם טועים בכתובת האינטרנט שמופיעה שם. הסיבה שיש כתובת אחרי ה DOCTYPE היא רק בשביל לזהות את הגירסה של ה HTML, ובעצם השורה מתפקדת בתור URI ולא URL - אף אחד לא משתמש בה כדי לקרוא את המסמך שנמצא בה. אותו סיפור קורס ב XML Namespaces וגם במזהים של schema.org.

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

למידע נוסף שווה לקרוא את הפוסט הזה מהבלוג של auth0 שעוזר לחדד את ההבדל בין המושגים: https://auth0.com/blog/url-uri-urn-differences/

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

"מבין או מבינה את הסיפור"

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

1. מה המטרות של הקוד הזה

2. מה האילוצים שהקוד צריך להתמודד איתם

3. מה היו האילוצים של מי שכתבה את הקוד

4. איזה חלקים שם בכוונה ומה שם בטעות

5. מה הולכות להיות הבעיות בקוד הזה בעתיד הקרוב

6. איזה בעיות סביר להניח שיהיו לקוד הזה בעתיד היותר רחוק

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

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

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