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

@yossiz נכון מאוד, אבל לפעמים בהתחלה מתלהבים משיטה מסויימת ואז מגלים שיש לה קצת חסרונות פה ושם ומגיע איזה צוות חוקרים/מפתחים שמגלה שיטה יותר טובה, התכנות מלא בדוגמאות כאלו:
ירושות של כמה "דורות".
תבניות למיניהם.
פעם הפוקנציות היו רגילות ואז גילו את הגנריות.
סינכרוני מול אסינכרוני.
wep מול wpa
random פשוט שהיום (וכבר מזמן) ניתן לחזות בדיוק מה הוא יהיה ואף להכריחו ליצור ערך מסוים לעמות שיטות random כיום.
ועוד הרבה בכל סוגי המקצועות (כמו gsm->umts->lte->5g).
בעצם כמעט כל שפת תכנות טוענת שהיא יותר טובה מהקודמת.
השיטות שהיום "in" מחר כבר "out", מעין מה שנקרא buzz word.

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

@dovid כתב ביש חלופה טובה/עדכנית לרקורסיה?:

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

אני לא מבין כתבתי בפירוש

אבל נשמע שהיום זה פחות מומלץ

אני לא יודע אני שואל...

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

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

מחילה, לא רואה בעיה במה שאמרתי.

שוב ושוב נהיה מצב שבמקום לענות לך מתחילים לדון על הנחות היסוד שלך הנסתרות/הנגלות.

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

@pcinfogmach כתב ביש חלופה טובה/עדכנית לרקורסיה?:

@eido
במחילה
מה בדיוק אתה מנסה לעושת שלוקח יותר מ-6 דקות זמן ריצה על ידי רקורסיה?

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

ולמה החלטת שאי אפשר לעצור רקורסיה באמצע?

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

@meir-lamdan גם באופן כללי אבל עכשיו מה שעומד מולי זה google script שם הזמן ריצה מוגבל ל6 דקות שזה ממש מעט לרקורסיה.

@meir-lamdan בזבזני, לא ניתן לעצור באמצע אם צריך ולהמשיך אח"כ.

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

@dovid כתב בסליקת אשראי דרך api:

strip

לכאורה גם הם לא נותנים אפשרות כזו.

@dovid כתב בסליקת אשראי דרך api:

cardknox

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

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

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

לא מובן לי כל הAPI הזה.

@dovid כתב בסליקת אשראי דרך api של paypal:

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

אני מסכים איתך לגמרי

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

להם יש API כזה?

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

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

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

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

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

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

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

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

לא הבנתי כלום

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

מקוה שהייתי מובן הפעם.

@צדיק-תמים כן, אני משתמש בזה מאז.

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

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

או שלא הבנתי משהו נכון?

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

@צדיק-תמים לא, הפעם הוא נקודתי ממש

try {
            //    toDo = await call.read(tempAd,
            toDo = await call.read([...tempAd,{ type: 'file', data: `/ivr_records/שמיעה1` }],
                'tap',
                {sec_wait: 2, min_digits: 1, typing_playback_mode: "No", digits_allowed: [1, 2, 3, "*0"] });
                }
                finally{
                console.log("מסמן כנקראה");
               await updateBuyerAds(paramAndAdsContent[indexOfSubscrib].ads.new[i1].adId, call);
            //    console.log(`סימן כנקראה את מודעה ${paramAndAdsContent[indexOfSubscrib].ads.new[i1].adId}`);
            }

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

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

בהמשך לנאמר כאן לגבי ספרית yemot router (nodejs)

הid_list_message בלי פרמטר prepend to next זורק שגיאה

אם אתה לא עושה עליה try catch אז הפונקציה נעצרת והשגיאה מטופלת על ידי הראוטר

אם אתה עושה try catch ולא בודק את סוג השגיאה, זה בעיה

בכללי אין סיבה בדוגמאות שהבאת לעשות try catch כי יש הנדלר גלובלי לשגיאות לא צפויות

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

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

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

אשמח לעזרה בנושא.