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

@dovid אמר בnodejs הגדרת פונקציית השרת כ async:

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

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

כמו ש@רפאל אמר אם רוצים להשיג כזו התנהגות יש להשתמש בגירסה 5 או לעשות טריי עם Next(err) בכל מקום.

נ.ב. כתבת בטעות סינכרונית התכוונת אסינכרונית.

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

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

זו הדרך שאני משתמש באקספרס, ולמיטב הבנתי זו דרך המלך:

צורה 1:

router.get("/", (req, res, next) => {
  getAllUsers()
    .then((users) => {
      res.status(200).json(users);
    })
    .catch((err) => {
      const { code, message } = err;
      res.status(err.status).json({ code, message });
    });
});

צורה 2:

router.get("/", async (req, res, next) => {
  try {
    const users = await getAllUsers();
    res.status(200).json(users);
  } catch (err) {
    const { code, message } = err;
    res.status(err.status).json({ code, message });
  }
});

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

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

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

process.on("uncaughtException", (err) => {
  console.error("There was an uncaught error", err);
  //   process.exit(1); //mandatory (as per the Node.js docs)
});

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

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

@צדיק-תמים אמר באיזה ספרייה/פריימוורק (מה זה בכלל, בעצם?...) מומלץ ללמוד כיום?:

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

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

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

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

@dovid אמר באיזה ספרייה/פריימוורק (מה זה בכלל, בעצם?...) מומלץ ללמוד כיום?:

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

נ.ב. אני לא מכיר טוב שום פרימוורק מהנידונים פה.

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

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

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

@יוסף-בן-שמעון אמר באיזה ספרייה/פריימוורק (מה זה בכלל, בעצם?...) מומלץ ללמוד כיום?:

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

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

@ארכיטקט אמר באיזה ספרייה/פריימוורק (מה זה בכלל, בעצם?...) מומלץ ללמוד כיום?:

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

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

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

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

מקוה שהנמשל ברור...

@zvizvi אמר בתאריך עברי ב VEU:

אני גם צריך כזה. אולי אכין אחד (לא מתחייב על תאריך יעד מוגדר...)

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

@חוקר אמר בתאריך עברי ב VEU:

@davidnead אמר בתאריך עברי ב VEU:

@חוקר אם הצבעת ולא הגבת אני מבין שעלי ללמוד שלא בנית? איך כן הסתדרת?

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

קיויתי לבשורה טובה יותר.

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

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

@חוקר אם הצבעת ולא הגבת אני מבין שעלי ללמוד שלא בנית? איך כן הסתדרת?

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

@צדיק-תמים אמר באיזה ספרייה/פריימוורק (מה זה בכלל, בעצם?...) מומלץ ללמוד כיום?:

@davidnead אמר באיזה ספרייה/פריימוורק (מה זה בכלל, בעצם?...) מומלץ ללמוד כיום?:

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

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

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

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

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

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

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

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

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

וואו! תודה רבה. ההסברים שלך בהירים ואתה גם טורח עליהם להגיש אותם היטב.
בהתחלה הייתי בטוח שפיספסת את נקודת השאלה, עד שתפסתי שאני פיספסתי את הנקודה בתשובה:

אם הבנתי נכון, יוצא לי שהשמה זו חייבת שה-shape של el יהיה זהה ל-shape של החלון שחצבת ב-tile

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

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

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

tile[i*x_size:(i+1)*x_size, j*x_size:(j+1)*x_size] = el

הtile הוא מערך עם shape של (7200,7200), בעוד הel הוא מערך עם shape של (3600,3600).

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

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

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

        let maxarg = 0, max = 0
        tile.forEach((t, i) => {
            return t.reduce((p, c, ii) => {
                if (c > max) {
                    max = c
                    maxarg = (i * t.length) + ii;
                }
                return c
            })
        })

        const unravel_index = (arr, indices) => {
            const shape = [arr.length, arr[0].length];
            const [x, y] = [indices % shape[1], (indices - (indices % shape[1])) / shape[1]]
            return { x, y }
        }
        const { x, y } = unravel_index(tile, maxarg);