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

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

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

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

type Letter<Word extends string, R extends string[] = []> = 
  Word extends `${infer H}${infer T}` ? Letter<T, [...R, H]> : R[number];

// works! h is one of the letters in "hello"
const x: Letter<"hello"> = "h";

// compilation error! x is not one of the letters in "hello"
const y: Letter<"hello"> = "x";

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

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

הטיפוס מוגדר בתור Conditional Type. זה אומר שאם Word באמת מתאים לצורה:

`${infer H}${infer T}`

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

// compiles OK
const a: "a" = "a";

// compilation error - expecting only the letter "a"
const b: "a" = "b";

לכן H יהיה טיפוס של האות הראשונה במחרוזת, ו T יהיה טיפוס של מחרוזת שמורכבת מכל האותיות פרט לראשונה. המילה hello מתאימה לזה ועבורה ה H יהיה האות h קטנה וה T יהיה המחרוזת ello.

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

Letter<T, [...R, H]>

הטיפוס מוגדר להיות Letter של T, שזה רק הסוף של המילה, אבל הפעם הפרמטר השני R מקבל ערך התחלתי - כל מה שהיה בו קודם פלוס הטיפוס H כלומר האות h הקטנה. לכן השלב הראשון ברקורסיה היה המעבר:

Letter<"hello", []> => Letter<"ello", ["h"]>

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

Letter<"", ["h", "e", "l", "l", "o"]>

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

R[number]

בגלל ש R הוא מערך עם אותיות שידועות כולן בזמן קומפילציה, אנחנו יכולים לדבר על הטיפוס R[0] שהוא האות h, או הטיפוס R[1] שהוא האות e. אנחנו גם יכולים לדבר על הטיפוס R[number] שהוא איחוד של כל האותיות במערך, כי number יכול להתאים לכל מספר שהוא אינדקס חוקי במערך.

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

את הרעיון קיבלתי מוויליאם קנדילון, ואתם מוזמנים להמשיך לראות אותו גם בוידאו בו הוא בונה משחק וורדל שלם בעזרת טיפוסים בטייפסקריפט: https://www.youtube.com/watch?v=JT30j4nhej4

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

ומחכות.

ומחכות.

ומחכות.

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

בריאקט היחס יותר טוב - להם יש 16 מיליון הורדות בשבוע וכמעט 80 אלף צפיות בהרצאת הפתיחה של כנס React Conf האחרון. ואלה עדיין מספרים מאוד קטנים.

גם אם נסתכל רק על מספרים בתוך יוטיוב התמונה נשארת דומה. לקורס ריאקט למתחילים של Free Code Camp יש מיליון וחצי צפיות. עוד חמש מיליון צפיות הלכו ל mosh בקורס React For Beginners שלו, ו Ben Awad משך מיליון וחצי צפיות לראיון העבודה בריאקט שהוא העביר לקלמנט מיולשקו.

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

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

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

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

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

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

הצד השני של האתר, קוד ריילס שמפעיל אותו, קיבל ממני רוב השנים כתף קרה, ואפילו תיפקד בתור שפן ניסיונות שלי בלימוד טכנולוגיות: כתבתי מחדש את שיכבת ה Front End עם ריאקט ו react router בתור Single Page Application; אחרי זה החלפתי אותו בראוטר שלי שסינכרנתי לבד עם שרת הריילס; בדרך הקשה למדתי על האתגרים ב Server Side Rendering ואיך לפתור את רובם; מה זה Cache ואיך לבנות אחד ואיך לנהל נכון משימות רקע.

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

1. לבנות מערכת שצריכה הרבה פחות תחזוקה, ושהתחזוקה שלה תהיה קלה. זה אומר פחות JavaScript ופחות תלויות.

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

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

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

5. לרענן את העיצוב שיתאים לשנת 2022.

6. לסדר את מערכת ה Deployment כדי לקבל Zero Downtime Deployments רצוי דרך שרת CI/CD.

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

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

https://v2.tocode.co.il/

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

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

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

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

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

2. התחביר מאוד דומה לכתיב React רגיל, אבל הרבה דברים שונים. לדוגמה קומפוננטת TextInput שמייצגת תיבת קלט מקבלת מאפיין value עם הטקסט הנוכחי ומאפיין onChangeText (במקום onChange) שמטפל בשינוי טקסט. שינויי שמות וממשק כאלה יכולים להרגיז כשאנחנו לא מצפים להם.

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

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

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

פרטים נוספים והרשמה בדף הוובינר בקישור: https://www.tocode.co.il/workshops/118

נתראה בחמישי בבוקר.

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

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

const days = ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'];
const search = 'su';

const options = days.filter(d => d.toLowerCase().includes(search.toLowerCase()));

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

function clean(word) {
    return word
        .normalize('NFD')
        .replace(/\p{Diacritic}/gu, "")
        .toLocaleLowerCase() ;
}

const languages = ['Anglais', 'Français', 'Hébreu'];
const search = 'nc';

const options = languages.map(clean).filter(l => l.includes(clean(search)));

במבט ראשון הקריאה ל normalize נראית מיותרת:

>> 'Français'.normalize("NFD")
<- "Français" 

אבל האמת שהנורמליזציה הזו היא שמאפשרת לביטוי הרגולארי לעבוד. הנה השוואה איתה ובלעדיה:

>> "Français".replace(/\p{Diacritic}/gu, "")
<- "Français"
>> "Français".normalize('NFD').replace(/\p{Diacritic}/gu, "")
<- "Francais" 

אנחנו צריכים לנרמל מחרוזות יוניקוד בגלל שיש כמה דרכים לייצג תווי יוניקוד מיוחדים. אפשר לקרוא יותר לעומק על נורמליזציה ויוניקוד ב FAQ שלהם בקישור: http://www.unicode.org/faq/normalization.html

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

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

# 33 is the first unique number
items = [10, 22, 33, 10, 12, 22, 9, 5, 1]

counts = items.each_with_object(Hash.new(0)) do |item, acc|
  acc[item] += 1
end

first_unique_index = items.find_index {|item| counts[item] == 1 }

if first_unique_index
  puts "Unique Index = #{first_unique_index}; Item = #{items[first_unique_index]}"
end

פייתון:

from collections import Counter

# 33 is the first unique number
items = [10, 22, 33, 10, 12, 22, 9, 5, 1]

counts = Counter(items)

index, item = next(
        filter(lambda x: counts[x[1]] == 1, enumerate(items)),
        None)

print(f"First unique index is {index}; item is {item}")

ג'אווהסקריפט:

// 33 is the first unique number
const items = [10, 22, 33, 10, 12, 22, 9, 5, 1]
const counts = {};
items.forEach(i => counts[i] ? counts[i]++ : counts[i] = 1);

const index = items.findIndex(i => counts[i] === 1);

if (index) {
  console.log(`Found at index ${index} value ${items[index]}`);
}

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

echo 10 22 33 10 12 22 9 5 1 | tr ' ' '\n' | cat -n | sed 's/^ *//' | sort -k 2 -n | uniq -f 1 -c | sed 's/^ *//' | grep -w '^1' | sort -k 2 -n | cut -c 3- | head -1

בגדול זה טריק דומה, רק עקום - אנחנו מוסיפים אינדקסים לכל השורות עם cat -n, אחרי זה ממיינים לפי הערך כדי שנוכל להפעיל uniq -c שסופר כמה פעמים מופיע כל דבר, ואז עם grep נשארים רק עם אלה שמופיעים פעם אחת, ממיינים חזרה לפי האינדקסים ולוקחים את הראשון.

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

הרעיון לתרגיל הגיע ממוחמד מהגיליון האחרון של Perl Weekly Challenge בקישור: https://theweeklychallenge.org/blog/perl-weekly-challenge-180/#TASK1

ביום חמישי עוד שבוע וחצי אעביר פה וובינר על React Native. מקווה שתבואו. בינתיים עברתי על התיעוד של הספריות שרציתי להראות ונתקלתי בדוגמה הבאה מתוך התיעוד של React Navigation:

function HomeScreen({ navigation }) {
  const [count, setCount] = React.useState(0);

  React.useLayoutEffect(() => {
    navigation.setOptions({
      headerRight: () => (
        <Button onPress={() => setCount((c) => c + 1)} title="Update count" />
      ),
    });
  }, [navigation]);

  return <Text>Count: {count}</Text>;
}

עם הכיתוב הזה מעל הדוגמה:

To be able to interact with the screen component, we need to use navigation.setOptions to define our button instead of the options prop. By using navigation.setOptions inside the screen component, we get access to screen's props, state, context etc.

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

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

function HomeScreen({ navigation }) {
  const [count, setCount] = React.useState(0);

  React.useLayoutEffect(() => {
    navigation.setOptions({
      headerRight: () => (
        <Button onPress={() => setCount((c) => c + 1)} title={`Update count. Current value = ${count}`} />
      ),
    });
  }, [navigation]);

  return <Text>Count: {count}</Text>;
}

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

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

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

במעבר על קוד שווה לחלק את ההערות שלנו ל-3 קבוצות, או שלוש רמות של שיפורים אפשריים:

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

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

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

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