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

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

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

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

אז מה נשאר? שני דברים גדולים:

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

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

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

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

1. מבקש מ AI ליצור סקריפט.

2. מריץ ומתקן.

3. חוזר X פעמים.

4. הסקריפט עובד.

למה לשים לב:

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

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

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

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

5. העובדה שבחלק מהפעמים זה עובד היא לא פחות ממדהימה.

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

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

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

https://youtu.be/0jR4ws9T5Cs?si=3iTj_GmnPH3ln5J7

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

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

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

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

הסוד לכתיבת קוד יותר מהר הוא להבין קוד מהר יותר, וזה דורש אימון בלהבין קוד.

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

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

2. לקוחות ומפתחים מבולבלים לגבי היכולות של הטכנולוגיה - אנחנו לא מבינים איך מצד אחד כלי AI יכול לבנות מערכת שלמה מאפס אבל מצד שני לא מצליח לפתור תרגיל חשבון או לתקן באג פשוט. עוד לא פיתחנו אינטואיציה לגבי הטכניקות השונות לעבודה עם AI, מתי נעשה Fine Tuning לעומת Prompt Engineering, מתי צריך סוכן אחד ומתי כמה סוכנים, מה היכולות ומה המגבלות של כל שיטת עבודה.

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

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

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

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

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

8. גיוס ג'וניורים - הדגש הוא על מיומנויות רכות, מוטיבציה, חשיבה אנליטית, מוכנות ללמוד את הבסיס ויכולת ללמוד מה AI ולא לתת ל AI לכתוב במקומך. עדיף להתמקצע ב Vanilla JavaScript ולהכיר את העקרונות טוב מאשר ללמוד עוד Web Framework בלי להבין לעומק איך הוא בנוי.

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

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

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

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

https://www.tocode.co.il/talking_ai

מתכנתת חכמה מקבלת קוד מסורבל וחושבת-

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

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

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

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

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

הי חברים,

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

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

https://youtu.be/KvUVtKRs9EU?si=FJXSGtHBM91dkXwQ

וחלק שני מסביר איך להוסיף רכיבי ממשק משתמש לשרת ה MCP הזה כדי להפוך אותו לאפליקציה:

https://youtu.be/h0uQUfrv2oA?si=fz4e-pmM6uE7CxT6

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

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

https://github.com/ynonp/mcp-server-demo-deno

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

https://www.tocode.co.il/talking_ai

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

הנה כמה דוגמאות על מספרים:

3.3.5 :004 > 2 <=> 3
 => -1
3.3.5 :005 > 3 <=> 3
 => 0
3.3.5 :006 > 5 <=> 3
 => 1

ועל מחרוזות:

3.3.5 :011 > 'a' <=> 'b'
 => -1
3.3.5 :012 > 'b' <=> 'b'
 => 0
3.3.5 :013 > 'c' <=> 'b'
 => 1

במחרוזות "גדול מ..." אומר שהדבר נמצא אחרי הדבר השני בסדר מילוני.

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

3.3.5 :019 > [1, 2, 3] <=> [1, 5, 3]
 => -1

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

3.3.5 :023 > [major, minor, build] <=> [10, 4, 2]
 => 0

נ.ב. לפי ChatGPT אופרטור החללית עובדת בדיוק באותו אופן על מערכים גם ב PHP, C++, Groovy ו Elixir. בקלוז'ר הפונקציה compare אימצה את ההתנהגות וגם היא מטפלת במערכים באותה צורה.

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

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

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

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

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

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

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

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

וכך נולדה שרשרת האמון שאנחנו צריכים לתעד בכל מערכת שנבנה:

1. קוד שלי - אמון הכי גבוה, אני רואה את הקוד ושולט בסביבת הריצה.

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

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

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

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

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

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

parseInt(...)
Math.floor(...)
Math.round(...)
Math.trunc(...)
``

הבדלים? נשים לב:

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

```language-javascript
ynonp@ynons-MacBook-Air ~/tmp $ node
> Math.trunc(4.5)
4
> Math.trunc(4.8)
4
> Math.trunc(-4.8)
-4
> Math.trunc(-4.2)
-4
> Math.trunc("4.9")
4
> Math.trunc("4.9a")
NaN
>

1. החברות שלה Math.round ו Math.floor מתנהגות דומה לגבי מחרוזות אבל ישנו לכם את המספר בשליליים או כשהמספר קרוב לקצה:

> Math.round(2.3)
2
> Math.round(2.8)
3
> Math.floor(4.2)
4
> Math.floor(4.8)
4
> Math.floor(-4.8)
-5
>

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

> parseInt(3.4)
3
> parseInt(-3.4)
-3
> parseInt(-3.8)
-3
> parseInt(3.8)
3
> parseInt("2 apples")
2

לכן הטיפ היום כשהופכים שבר למספר שלם ב JavaScript מומלץ להשתמש ב Math.trunc. הכי מהירה והכי מדויקת.