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

כלים כמו WSL ו Docker מאפשרים לנו להריץ Shell Scripts של יוניקס על מכונת ווינדוס, אבל הבדל אחד בין מערכות ההפעלה עלול לקלקל את המסיבה, וזהו תו סוף שורה.

ב Unix תו סוף שורה הוא \n. ב Windows זה \r\n. ולכן סקריפט שאני כותב למשל ב Notepad ואנסה להריץ ב WSL ייכשל עם הודעת שגיאה בסגנון הבא:

-bash: ./test.sh: /bin/bash^M: bad interpreter: no such file or directory

עם כל זה אנחנו יכולים לחיות בקלות ופשוט לא לכתוב Shell Scripts ב notepad, אבל מה קורה כשכלי שאנחנו כן צריכים מחליט לשנות את תווי סוף השורה בסקריפטים שמישהו אחר כתב?

הכלי שאני מדבר עליו הוא גיט.

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

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

*.sh        text eol=lf

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

למידע נוסף על gitattributes וכל הדברים שתוכלו לכתוב בו שווה לבקר בספר בקישור: https://www.git-scm.com/docs/gitattributes

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

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

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

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

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

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

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

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

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

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

אם אתם כבר מנויים מוזמנים להיכנס לקורס ריאקט ולגלול לסוף הקורס בשביל הפרק החדש: https://www.tocode.co.il/bundles/react

אם אתם עדיין לא מנויים אז גם היום הוא יום טוב להירשם: https://www.tocode.co.il/quickjoin

ולינק אחרון לסיום - בתחילת ספטמבר אעביר כאן וובינר עם עיקרי הדברים על ריאקט נייטיב ואפשרות לשאול שאלות. הכניסה חינם וצריך רק להירשם בקישור: https://www.tocode.co.il/workshops/118

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

1. בדיקות - רק נסו להריץ בדיקות אחרי כמה חודשים בלי הרצה.

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

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

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

5. כלי עבודה - נו, חוץ מ vim.

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

לא צריך יותר מכמה דקות ביוטיוב כדי להיתקל בסרטים שמכילים את המילים Full Course: סרטים של שעתיים, שלוש ואפילו 8 שעות על טכנולוגיה מסוימת, בה מרצה בדרך כלל נחמד מספר ומספר על הטכנולוגיה, ואפילו בונה פרויקטים לדוגמה וכמובן הכל מצולם ומסודר. פה למשל יש מדריך פייתון של 4 שעות עם 35 מיליון צפיות: https://www.youtube.com/watch?v=rfscVS0vtbw

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

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

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

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

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

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

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

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

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

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

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

1. משחק סנייק

2. משחק טטריס

3. בלוג

4. צ'ט מיידי מרובה משתמשים

5. שידור וידאו "חי" עם הערות מהצופים

6. ניהול כספים אישי

7. משגר משימות (בסנון הזה)

צוותים שעובדים ב Agile רגילים להשתמש בקוד בתור הדרך "לגלות" את הבעיה או מה הלקוח רוצה. בין שנים עשר העקרונות האג'יליים השניים האלה מעבירים את המסר:

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

2. תוכנה עובדת היא המדד העיקרי להתקדמות.

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

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

אבל הבעיה שאנחנו לא חיים בספרינט בודד.

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

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

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

2. תשומת לב מתמשכת למצויינות טכנית ועיצוב ותכנון נכון מגדילים את היכולת האג'ילית.

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

החבילה json-to-ts היא חבילת JavaScript מדליקה (כתובה בטייפסקריפט כמובן) שיכולה לחסוך הרבה עבודה כשכותבים קוד שעובד מול APIs. התפקיד שלה הוא פשוט לקחת אוביקט JSON ולהפוך אותו ל Interface בטייפסקריפט, ואנחנו יכולים להשתמש בה בתוך תוכנית בצורה הבאה:

import JsonToTS from 'json-to-ts';
import fetch from 'node-fetch';
const url = process.argv[2];

async function main() {
  const json = (await (await fetch(url)).json());
  JsonToTS(json).forEach( typeInterface => {
    console.log(typeInterface)
  })
}

main();

ניקח URL לדוגמה שמחזיר אוביקט JSON:

$ curl https://swapi.dev/api/people/1/ | jq

{
  "name": "Luke Skywalker",
  "height": "172",
  "mass": "77",
  "hair_color": "blond",
  "skin_color": "fair",
  "eye_color": "blue",
  "birth_year": "19BBY",
  "gender": "male",
  "homeworld": "https://swapi.dev/api/planets/1/",
  "films": [
    "https://swapi.dev/api/films/1/",
    "https://swapi.dev/api/films/2/",
    "https://swapi.dev/api/films/3/",
    "https://swapi.dev/api/films/6/"
  ],
  "species": [],
  "vehicles": [
    "https://swapi.dev/api/vehicles/14/",
    "https://swapi.dev/api/vehicles/30/"
  ],
  "starships": [
    "https://swapi.dev/api/starships/12/",
    "https://swapi.dev/api/starships/22/"
  ],
  "created": "2014-12-09T13:50:51.644000Z",
  "edited": "2014-12-20T21:17:56.891000Z",
  "url": "https://swapi.dev/api/people/1/"
}

וזה מה שיוצא כשאני מעביר אותו לתוכנית שלי:

$ node tsify.mjs https://swapi.dev/api/people/1/

interface RootObject {
  name: string;
  height: string;
  mass: string;
  hair_color: string;
  skin_color: string;
  eye_color: string;
  birth_year: string;
  gender: string;
  homeworld: string;
  films: string[];
  species: any[];
  vehicles: string[];
  starships: string[];
  created: string;
  edited: string;
  url: string;
}

אז נכון צריך לסדר את השם RootObject וצריך להפוך את כל המערכים מ any[] לסוג הנכון שלהם, אבל במהלך כתיבת קוד כלי כזה יכול לחסוך הרבה זמן. עכשיו רק נשאר לכתוב vim plugin שייתן לי לכתוב בקוד משהו כמו:

interface https://swapi.dev/api/people/1/

ויהפוך את זה אוטומטית לתוצאה של הסקריפט.

בין הסוגים של קוד שאנחנו כותבים:

1. קוד שגורם לדברים לעבוד מהר יותר

2. קוד שפותר באג ללקוח

3. קוד שחוסך עבודה למתכנתת שכתבה אותו

4. קוד שמוסיף פיצ'ר שכל הלקוחות רואים

5. קוד שמוסיף פיצ'ר שרק חלק מהלקוחות רואים

6. קוד שגורם לדברים להיראות יפה יותר

7. טקסט שמסביר מה קוד שכתבתי עושה

8. קוד שמשפר את החוויה כשיש מצב שגיאה

9. קוד שבודק קוד אחר

10. קוד שמשפר את החיים של מתכנתים אחרים בצוות

11. קוד שעוזר לי להבין רעיונות חדשים

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

איזון בקוד יוצר מערכות יציבות יותר ומתכנתים שמחים יותר.

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

ואז התחילו הבעיות:

1. הבוט החדש לא הצליח לפצל הודעות ארוכות כמו שצריך

2. הבוט החדש לא שלח הודעות Markdown אלא טקסט רגיל, ולכן דוגמאות הקוד הופיעו שבורות בערוץ.

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

1. את הקוד כתבתי ישירות על שרת ה Production ב vi.

2. את הטוקן של טלגרם כתבתי Hard Coded בתוך הסקריפט.

3. על Source Control או בדיקות לא היה מה לדבר.

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

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

1. להעביר את הקוד לגיט מסודר.

2. להוסיף בדיקות ל flows החשובים או לפחות לאלה שהיו שבורים.

3. לבנות מנגנון Deploy מסודר שישתמש ב CI (במקום להעתיק קבצים עם rsync).

4. להעביר החוצה סודות למשתני סביבה.

וזה בדיוק היה שלב 2 בפיתוח הבוט, שאולי חלקכם שמתם לב אליו בפירסומים והמחיקות שעשיתי במהלך אתמול. הקוד המעודכן של הבוט עלה לגיטהאב ואתם מוזמנים לקרוא אותו כאן: https://github.com/ynonp/blog-to-telegram

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

תוספת שניה לקוד היא הקובץ .github/workflows שמעלה מכונה שמתקינה את כל התלויות ומריצה את התוכנית פעם ביום בשעה שמונה בבוקר. אני מקווה שהמעבר ל Github Action יגרום לסקריפט להיות יותר יציב ולא להישבר גם אם השרת עמוס או שודרג. זה ה Workflow:

# This workflow will install Python dependencies, run tests and lint with a single version of Python
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-python-with-github-actions

name: publish-daily-post-to-telegram

on: 
  workflow_dispatch:
  schedule:
    - cron:  "0 8 * * *" 


permissions:
  contents: read

jobs:
  publish:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python 3.10
      uses: actions/setup-python@v3
      with:
        python-version: "3.10"
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
    - name: run
      env:
        TELEGRAM_TOKEN: ${{ secrets.TELEGRAM_TOKEN }}
      run: |
        python blog_to_telegram/publish_daily_post.py

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

כמובן ששלב שני הוא לא סוף הדרך. נשאר עוד:

1. להוסיף Workflow שכל פעם שדוחפים קוד חדש יריץ אוטומטית את כל הבדיקות.

2. להוסיף בדיקות (כרגע יש רק בדיקות למנגנון פיצול ההודעות).

3. להוסיף קובץ Readme ותיעוד בתוך הקוד.

אבל זה יחכה לבאג הבא או ל Pull Request מכם. מה שיבוא קודם.