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

טיפים קצרים וחדשות למתכנתים

כשאני יודע יותר מהמחשב

02/05/2021

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

interface IObject {
  a: number;
  b: number;
}

const o : IObject = { a: 10, b: 20 };
const k = JSON.parse('"a"');

console.log(o[k]);

זה קוד TypeScript שלא עובר קומפילציה למרות שאין בו אף טעות.

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

ניסיון לקמפל את הקוד מקפיץ את השגיאה:

Element implicitly has an 'any' type because expression of type 'any' can't be used to index type 'IObject'.

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

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

  1. אפשר לבקש מ TypeScript שיעזוב אותי בשקט ולא ישמור על המשתנה o בכלל.

  2. אפשר להגיד ל TypeScript שאני יודע מה שאני עושה והתצואה של JSON.parse באמת הולכת להיות מפתח מתוך הממשק IObject.

הכיוון הראשון נראה כך ומתקמפל:

interface IObject {
  a: number;
  b: number;
}

const o : Record<string, any> = { a: 10, b: 20 };
const k = JSON.parse('"a"');

console.log(o[k]);

והכיוון השני נראה כך וגם מתקמפל:

interface IObject {
  a: number;
  b: number;
}

const o : IObject = { a: 10, b: 20 };
const k: keyof IObject = JSON.parse('"a"');

console.log(o[k]);

האם באמת צריך להכיר 5 פיתרונות לאותה הבעיה?

01/05/2021

שאלה זריזה (אל תספרו לי את התשובה. תענו בראש): כמה מכם, אחרי שסיימתם לכתוב פיצ'ר או לפתור באג, חוזרים אחורה עם git reset --hard ואז מנסים פיתרון נוסף? ופיתרון שלישי? ורביעי? וחמישי?

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

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

אבל...

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

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

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

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

האם באמת צריך להכיר 5 פיתרונות לאותה הבעיה? אם אנחנו מכוונים להיות המתכנתים הכי מקצועיים שאנחנו יכולים - התשובה בהחלט כן.

ההחמצה הראשונה

30/04/2021

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

איך זה קורה?

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

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

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

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

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

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

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

איך ליצור Docker Image בלי Dockerfile

29/04/2021

הדרך המקובלת ליצור אימג' לדוקר היא לכתוב Dockerfile, שזה קובץ עם הוראות לדוקר איך בדיוק לבנות את האימג'. שימוש ב Dockerfile עוזר לשמור על סדר:

  1. דוקרפייל הוא קובץ בפורמט טקסט, כך שאפשר להתייחס אליו בתור קוד מקור לכל דבר.

  2. אפשר לשמור את ה Dockerfile בגיט ולנהל עליו גירסאות.

  3. אפשר לשתף את ה Dockerfile עם חברים כדי שיוכלו בעצמם לבנות את האימג' לפי אותן הוראות.

  4. קל מאוד לתחזק אימג'ים ולשנות אותם כשיש לך ביד את ה Dockerfile שבונה את האימג'.

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

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

זה עובד ככה:

  1. יוצרים קונטיינר חדש ומריצים אותו, למשל עבור אלפין לינוקס אפשר להפעיל:
$ docker run -d --rm alpine sleep infinity
  1. נכנסים לקונטיינר ומתחילים ליצור שם קבצים או לשנות דברים במכונה (שימו לב לשנות את ה Container ID לערך שמופיע אצלכם):
$ docker exect -it 2b090ffbd1fb /bin/sh
  1. בשביל המשחק אני מפעיל בתוך המכונה את הפקודה הבאה כדי ליצור משתמש חדש:
/ # adduser ynon

אחרי שבחרתי סיסמה אני יוצא מהקונטיינר ובמכונה הראשית שלי מפעיל (שוב שימו לב להחליף את ה Container ID למה שמופיע אצלכם):

$ docker commit 2b090ffbd1fb
  1. הקומיט יצר אימג' חדש, וכשנסתכל ב docker images נוכל לראות אותו עדיין ללא שם:
<none>               <none>          3030ab2039c3   30 seconds ago   5.58MB
  1. נשאר רק לתת שם לאימג' כדי שאפשר יהיה לדחוף אותו ל docker hub (ושוב שימו לב לשנות את ה Image ID לזה שהופיע אצלכם, ואת שם האימג' למשהו שמתאים למשתמש דוקרהאב שלכם):
$ docker image tag 3030ab2039c3 ynonp/commit-demo
  1. ובסוף אפשר לדחוף את האימג' החדש לדוקרהאב כדי שכולכם תוכלו להשתמש בו:
$ docker push ynonp/commit-demo
  1. אלה מכם שירצו לשחק עם האימג' החדש שיצרתי צריכים עכשיו רק להריץ:
$ docker run -it --rm ynonp/commit-demo /bin/sh

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

ארבע שנים ניסיון

28/04/2021

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

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

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

שני טיפים על הנושא הזה:

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

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

איך למזג קבצי JSON (או כל קובץ מיוחד אחר) עם git

27/04/2021

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

דוגמה קלה היא קבצי JSON, ובמיוחד הקובץ package.json למתכנתי Front End או מתכנתי Node.JS. כשאנחנו מוסיפים מודול בענף אחד בגיט, ובענף אחר מוסיפים מודול אחר, כמעט תמיד נקבל קונפליקט. הנה דוגמה קטנה של package.json אחרי ניסיון merge, כשענף אחד התקין מודול בשם cowsay וענף אחר התקין מודול בשם mocha:

{
  "name": "driverdemo",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
<<<<<<< HEAD
  "dependencies": {
    "cowsay": "^1.4.0"
=======
  "devDependencies": {
    "mocha": "^8.3.2"
>>>>>>> feature2
  }
}

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

דרייבר מיזוג, או merge driver, הוא פשוט תוכנית ש git יפעיל כשהוא צריך למזג שני קבצים. התוכנית תקבל בתור פרמטרים את שני הקבצים וגם את הקובץ בגירסת ה merge-base שלהם, כלומר הקובץ "המקורי" ממנו שניהם יצאו.

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

דרייבר מיזוג שכבר קיים ועובד טוב לקבצי JSON נקרא git-json-merge. אני ממליץ להסתכל גם על הקוד שלו כדי לראות איך נראה merge driver וכי בסך הכל הוא די פשוט. בשביל להתקין את הדרייבר נפעיל:

npm install --global git-json-merge

ועכשיו נמשיך להגדיר את git-json-merge בתור הדרייבר שימזג קבצי JSON בפרויקט שלנו. קודם כל יש ליצור בתיקיית הפרויקט קובץ בשם .gitattributes ובו התוכן הבא:

*.json merge=json

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

הקובץ השני בסיפור שלנו הוא .git/config שם נוסיף את הבלוק:

[merge "json"]
    name = custom merge driver for json files
    driver = git-json-merge %A %O %B

הפקודה git-json-merge היא התוכנית שהרגע התקנו, ושלושת האותיות אחריה מייצגות את שלושת הגירסאות של הקובץ: %A הקומיט מהענף הנוכחי, %O הקובץ המקורי מ merge-base ו %B הקובץ מהענף השני.

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

{
  "name": "driverdemo",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "mocha": "^8.3.2"
  },
  "dependencies": {
    "cowsay": "^1.4.0"
  }
}

ואם יש לכם קבצים נוספים בפורמטים יצירתיים שווה להסתכל בקוד של git-json-merge ולכתוב גירסה מותאמת למיזוג הקבצים שלכם.

על ההבדל בין -c ו -s ב su ו runuser

26/04/2021

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

המשך קריאה

איך לקרוא קובץ ב Bash בלי cat

25/04/2021

בקבוצה [https://t.me/bash_tips] בטלגרם פורסמו לפני כמה ימים מספר אתגרי bash באתר שנקרא cmdchallenge.com. מאחר ויש לי חולשה לאתגרים מסוג זה הלכתי להעיף מבט. התחושה שלי היתה שרוב האתגרים שם לא היו מאוד מעניינים או לא היו מנוסחים מספיק טוב, אבל היה טריק אחד שתפס את העין.

בתרחיש המדובר הגענו למערכת קבצים שנמחקו ממנה כל התוכניות והיה צריך באמצעות Bash Builtins בלבד להציג תוכן של קובץ. האינטואיציה הראשונה שלי היתה להשתמש בפקודת read בלולאה, כמו בשורה הבאה שמדפיסה את כל תוכן הקובץ /etc/shells:

while IFS= read -r; do echo "$REPLY"; done < /etc/shells

אבל מסתבר שיש טכניקה יותר פשוטה ואחרי חיפוש קצר ב man bash מצאתי את הפיסקה הבאה:

The command substitution $(cat file) can be replaced by the equivalent but faster $(< file).

מה שאומר שאפשר לקצר את השורה לגירסה הבאה:

echo "$(< /etc/shells)"

שווה לשים לב למרכאות סביב המשתנה (בשני המקרים). ברוב הקבצים לא תשימו לב להבדל, אבל אם בקובץ יהיו סימנים מיוחדים כמו *, [] או ? הגירסה בלי המרכאות תתיחס לסימן המיוחד בתור תבנית של שם קובץ ותחליף אותו ברשימת כל הקבצים המתאימים לתבנית.

תשתית לשינויים

24/04/2021

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

"תוסיף בבקשה הערות"

"הבדיקה לא מספיק טובה"

"מה קורה במצב ש... ?"

"תמעך את הקומיטים בבקשה שיהיה רק קומיט אחד ב PR"

"תהפוך את הטאבים לרווחים"

"יש לנו API חדש שבדיוק מתאים למה שכתבת, עדיף שתעבור להשתמש בו"

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

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

תשתית של שינויים מורכבת מידע, מכלים ומעיצוב הקוד:

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

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

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

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

איך ולמה להקים Fanout Exchange ב RabbitMQ

23/04/2021

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

המשך קריאה