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

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

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

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

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

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

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

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

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

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

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

או במקרה של ג'סט, יכול להיות שאפשר להשתמש בספריית בדיקה אחרת; יכול להיות שאפשר להפעיל eject או לוותר על create-react-app לחלוטין.

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

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

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

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

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

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

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

במהלך וובינר על Next.JS שהעברתי אתמול ניסיתי לשלוח הודעה לשרת מתוך curl עם הפקודה הבאה:

$ curl -X POST -d hello 'localhost:3000/api/todos'

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

export default function handler(req, res) {
  console.log(`add ${JSON.stringify(req.body)}`);
  addTodo(req.query.text);
  console.log(`todos = ${JSON.stringify(getTodos())}`);
  res.status(200).json({});
}

וכמו שקורה לעתים קרובות כשמנסים לאלתר במהלך Live Coding הקוד לא עבד. במקום ש req.body יכיל את המילה hello כמו שהתכוונתי שיקרה, הוא הכיל אוביקט. תוצאת ההדפסה היתה:

add {"hello":""}

כלומר req.body הכיל אוביקט עם מפתח יחיד בשם hello וערך ריק.

מה?

בחזרה ל curl, המתג -d אומר שמה שיבוא אחריו הוא גוף ההודעה, והמתג -X POST אומר שאני שולח בקשה מסוג POST. בסך הכל יש לנו בקשת POST שגוף ההודעה שלה מורכב מהמילה הבודדת hello. אז איך req.body הגיע להיות אוביקט, ואיך hello הגיע להיות המפתח?

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

הפופולריות של דוקר וקוברנטיס הביאה לתודעה הציבורית גם את פורמט קבצי ההגדרות yaml, שזה קיצור ל Yaml Ain't Markup Language (בגירסה המקורית זה היה yet another markup language).

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

הנה דוגמה אחת לבור כזה שפגשתי לאחרונה - הקוד הבא ב docker-compose.yml מפעיל ubuntu שידפיס את הטקסט yes we can:

version: "3.9"

services:
  app:
    image: ubuntu
    command: bash -c "echo $$text"
    environment:
      text: yes we can

אבל אם נשנה את הטקסט ונישאר רק עם המילה yes:

version: "3.9"

services:
  app:
    image: ubuntu
    command: bash -c "echo $$text"
    environment:
      text: yes

אז הפלט משתנה בהתאמה והופך למילה הבודדת true.

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

הסקרנים שביניכם יכולים למצוא את מסמך הכללים המלא של יאמל בקישור: https://yaml.org/spec/1.2.2/, אבל אני לא בטוח שהקריאה בו תעשה לכם חשק לכתוב יותר יאמלים.

המייל הזה הגיע היום-

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

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

ואז היה לינק לתשלום עבור החבילה שלי.

בואו נדבר עליו.

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

מצד אחד הגישה "הפשוטה" לחיבור ריאקט לקוד צד שרת עובדת גם בעבודה מול Node: אנחנו בונים API באקספרס שיודע לטפל ב CORS, מתוך ריאקט שולחים בקשות Ajax ל API הזה ומציגים את התשובות. אפליקציית ריאקט מוגשת בצורה עצמאית מתוך nginx, שמשמש גם בתור Reverse Proxy ל Express.

אבל אני לא בטוח שהגישה הזאת מספיק פשוטה או מספיק מומלצת. בין הבעיות שלה:

1. אין תמיכה ב Server Side Rendering.

2. אין דרך קלה לשתף קוד בין אפליקציית הריאקט לאפליקציית ה Node.JS.

3. צריך לבנות לבד מנגנוני Build לשתי הסביבות.

4. צריך להתארגן על שרת ו nginx, ולתחזק אותו.

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

בוובינר השבוע נדבר על אותו Next.JS ונראה איך להשתמש בו כדי לחבר בין React ל Node.JS, וליישומי ענן נוספים כולל יישומיים מספקים אחרים. את הוובינר אני אעביר יחד עם ניר פריזיאן, ויחד אנחנו נראה:

1. איך לבנות יישום Next.JS מאפס.

2. איך להריץ אותו במצב פיתוח.

3. איך Next.JS מחברת בין קוד ריאקט לקוד Node.JS, איך בונים API Endpoints ואיך מפעילים Server Side Rendering.

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

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

לפרטים והצטרפות מוזמנים להיכנס לדף הוובינר בקישור: https://www.tocode.co.il/workshops/111