תחומים - פורום חרדי מקצועי

זה לא שאלה של נכון ולא נכון, יש הרבה גישות שונות ומקובלות
לדוגמה בפייתון נפוצה הגישה של לזרוק exception כדי לתקשר דברים בקוד, ובכללי לנסות קודם כל לבצע את הפעולה ולתפוס שגיאות צפויות (EAFP)
בJS מקובל יותר תכנות הגנתי ולזרוק שגיאה על שגיאה לא צפויה
בגו צריך להחזיר פרמטר של שגיאה והקורא בודק שהוא לא null
בSwift יש keyword ייעודי לסמן פונקציה שיכולה להיכשל ואז הקורא חייב לקרוא לה עם try ולטפל בשגיאות
וכן הלאה

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

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

@לא-מתייאש כתב במה עונים ללקוחות ששואלים האם אפשר לבנות את מה שאני בונה בAI?:

האנושות בנוייה בצורה שצריך מישהו שיהיה חייב במקרה של בעייה, אני גם בטוח ב-1000% שAI נוהגת פי 10 יותר טוב מרוב רובם של האנשים, הבעייה היא במקרה של תנועה מי חייב ? וודאי לא הAI, מי ישלם ? וודאי לא TESLA, אז מי ?
אז הAI אוליי יודעת יותר טוב את החוקים אבל צריך מישהו שיוכלו ליפול עליו.

אז עדיף שימותו כל שנה מליון איש העיקר שיהיה את מי להאשים?
כבר כיום יש לרכב אוטונומי 92% פחות תאונות קטלניות (הנתון הנ"ל על waymo אבל טסלה גם הרבה יותר בטוח)

תחפור קצת יותר...
לדוגמה https://github.com/hasadna/open-bus-backend/blob/main/src/controllers/gov.controller.js
הכל קוד פתוח אפילו התשתיות (IaC)

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

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

@eido אוקיי זה נכון, אבל אם אתה לא בודק שהמאזין באמת שמע או משהו כזה אין לך עניין לסמן רק אחרי
אתה יכול לסמן ואז לעשות read

@eido כן, כי אתה זורק את השגיאה שוב מחוץ לבלוק try
רק מה ש try { פה } נתפס
אבל אתה לא אמור להגיע למצב כזה בדרך כלל, כי אתה לא אמור לעטוף קטעי קוד גדולים
בכל מקרה עדיף שתזרוק מחדש בcatch ולא בfinnaly כי אז יש לך את המשתנה של השגיאה לזרוק אותה מחדש

@eido כתב בפעולת try/finally מפריע לcatch שמעליו או לא - nodejs:

עצם הבלוק try תופס שגיאות

כן
אם אתה עושה try finally אתה פשוט בולע את השגיאה
ממליץ על הספר https://hebdevbook.com/product/jsheb/

@eido הid_list_message בלי פרמטר prepend to next זורק שגיאה
אם אתה לא עושה עליה try catch אז הפונקציה נעצרת והשגיאה מטופלת על ידי הראוטר
אם אתה עושה try catch ולא בודק את סוג השגיאה, זה בעיה

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

@eido כתב בלוגי שגיאה בnodejs וyemotrouter מה הגורם לקריסה?:

אבל זה תופס את כל החריגות?

כל החריגות שלא נתפסו קודם - uncaughtErrorHandler

איך זה עובד?

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

@dovid הכי טוב היה בלי try בלבד חוץ מנקודתי בשורה שרוצים לטפל בשגיאות שלה בצורה שונה
יש לספריה קאלבק מיוחד כדי לטפל בשגיאות לא צפויות בצורה מרוכזת במקום לפזר בקוד try catch

@eido ולמה עדכון מספר טלפון אי אפשר לעשות עם אימות מספר נוכחי?

@eido כתב בעזרה בתכנון מבנה מערכת:

לגופו של ענין, אין הצעות לדברים נצרכים?

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

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

@eido כן, זה עקרון חשוב מאוד שחוסך הרבה באגים וסרבול

@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

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

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

@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

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

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

@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

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

מה שהציעו לך באשכול השני זה לא לשכפל את המידע

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

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

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

---

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

@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

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

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

לא כ"כ הבנתי את ההצעה שלך, אני לא כ"כ חזק בsql ומסדי נתונים.

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

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

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

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

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

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

@eido הבעיה היא שאתה משכפל נתונים (מודעות) שאמורים להיות שאילתה
שאילתה לא אמורה להיות סיבוך, בשביל זה אתה עובד עם SQL ולא עם קבצים בדיסק

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