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

@dovid אמר בפרומיסים לוקחים זמן?:

@davidnead אני לא מבין מה שהוא כותב עם האחוזים, אבל זה לא נוגע לך, מבטיח לך.

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

וגם הV8 היה מחסל ממזמן את הבעיה ע"י אופטימיזציה שמתעלמת מהasync המזוייף.

אממ... הגיוני.

תודה גם לך

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

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

אז לגוף השאלה:
אתה אומר שהמשמעות זניחה ולא אמורה להטריד אותי. היות שאני מדבר על מקרה שאמור להיות מאתגר מבחינת ביצועים והמהירות חשובה לי מאוד ברמת חלקי שניות (עשרות קריאות לפונקציה רקורסיבית שמורצת בסוף מאות פעמים, כשאני מצפה מהשרת לתשובה בזמן אפס או קרוב לכך), לא התעצלתי ועשיתי את הגוגל אליו שלחתי אותי, שהוביל אותי למאמר הבא:
https://madelinemiller.dev/blog/javascript-promise-overhead/

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

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

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

async function getData() {
  const res = await readFiles("path");
  return res;
}
async function run() {
  const res = await getData();
  console.log(res);
}

במקום קוד כזה:

function getData() {
  return readFiles("path");
}
async function run() {
  const res = await getData();
  console.log(res);
}

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

@dovid אמר בפרומיסים לוקחים זמן?:

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

חידה לי דבריך. לא להמתין - לא בגלל מהירות, אלא כדי לתת ללקוח תשובה כמה שיותר מהר??

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

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

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

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

async function getData(userData) {
  if (userData.type == undefined) {
    userData.type = await readFile(`path/to/${userData.id}`);
  }
  return userData.type == "manager" ? "secreet data" : "free data";
}

router.get("/", async (req, res, next) => {
  const userData = req.body.userData;
  let result = await getData(userData);
  res.send(result);
});

לעומת זאת, יכולתי לכתוב את הקוד בצורה כזו:

async function getData(userData) {
  return userData.type == "manager" ? "secreet data" : "free data";
}

async function getUnexpectedData(userData) {
  userData.type = await readFile(`path/to/${userData.id}`);
  return userType == "manager" ? "secreet data" : "free data";
}

router.get("/", async (req, res, next) => {
  const userData = req.body.userData;

  let result;

  if (userData.type == undefined) {
    result = await getUnexpectedData(userData);
  } else {
    result = getData(userData);
  }
  res.send(result);
});

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

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

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

function a(cb){
    cb()
}
a(()=>console.log(1))
console.log('fast code win!!')

הפעם 1 יודפס לפני 'fast code win!!', למרות שהוא בתוך קולבק. היות שהוא לא כולל בתוכו שום פעולה שדורשת התנהגת סנכרונית, הקולבק מתבצע קודם.
כלומר לפרומיס יש התנהגות מיוחדת, זו לא סתם העברת כל הקוד אל תוך קולבק. הפרומיס זה אובייקט שכביכול מניח מראש שיש בתוכו פעולה סנכרונית, ולפיכך מריץ את הקלבק שלו ומתחיל להתבצע רק אחר סיום הקוד שאחריו.
אז בהחלט מובן שawait הוא סוכר תחבירי לקלבק, זה אני מבין. אבל פרומיס הוא לכאורה התנהגות אמיתית שונה. ואם זה נכון - זה מחזיר את השאלה האם כדאי להשתמש בו כשלא צריכים אותו. בהנחה שהוא מתנהג בצורה שונה בכך שהוא מפעיל את הקולבק שבתוכו רק בסיום הevent loop, ואם כן הוא מצריך להמתין לו אם רוצים לשמור על התזמון, שזה אומר בעצם להעתיק את כל הקוד שאחריו על תוך הקולבק של הפרומיס - שמופעל אחרי שכל קוד אחר שמחוץ לפרומיס מתבצע.

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

מקוה שהייתי מובן.

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

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

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

async function doSomthimg() {
  let a = 0;
  for (let i = 0; i < 100; i++) a++;
  return a;
}

router.get("/", async (req, res, next) => {
  let result = await doSomthimg();
  res.send(result);
});

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

לעומת

function doSomthimg() {
  let a = 0;
  for (let i = 0; i < 100; i++) a++;
  return a;
}

router.get("/", async (req, res, next) => {
  let result = doSomthimg();
  res.send(result);
});

(את הasync בשורה 7 בדוגמה האחרונה השארתי בכונה).

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

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

@mdy אמר בהשכרת מכשיר מוגן עם אפליקציית השכרת רכב:

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

אבל מה יהיה שאני צריך רק ליומיים ולא לקנות?

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

@צדיק-תמים אמר במה הקוי אורך-רוחב לחישוב זמני היום?:

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

ראה הקישור בהודעתי הקודמת אחרי העריכה.

@צדיק-תמים אז מה אתה כן רוצה?
אתה רוצה רשימה מוכנה של מיקומים, לא תלויית API חיצוני, זה אני מבין.
לא איכפת לך מהיכן לקבל, או שאתה רוצה איזה שיקול הלכתי או אחר בהגדרת הרשימה?
סתם רשימתמיקומים אפשר למצוא בגוגל פשוט, למשל כאן:
https://simplemaps.com/data/world-cities
40 אלף. מספיק?

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

@צדיק-תמים אמר במה הקוי אורך-רוחב לחישוב זמני היום?:

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

לא הבנת אותי, אבל לא חשוב, הבנתי מה חסר לך, זה:

Hebcal.Location.lookup("Jerusalem")

מכאן:
https://github.com/hebcal/hebcal-es6/blob/main/src/location.js

חפש "classicCities0", לא הצלחתי ליצור קישור למילים. יש להם 60 ערים קלאסוית.

ובקוד עצמו:

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

@צדיק-תמים אמר במה הקוי אורך-רוחב לחישוב זמני היום?:

@davidnead אמר במה הקוי אורך-רוחב לחישוב זמני היום?:

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

כמו שציינתי לעיל גם לapi של hebcal יש רשימה די מכובדת
הבעיה שאני לא רוצה להסתמך על הAPI שלהם.

על מה אתה כן רוצה להסתמך? על פי מה הייתה רוצה לקבוע? הרב גוגל?

@dovid אמר במה הקוי אורך-רוחב לחישוב זמני היום?:

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

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

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

2. מהיכן לקבל את זמני היום התואמים לקורדינטות

3 אפשרויות לפניו, שלושתם נפוצות מאוד:

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

@שואף אמר במה הקוי אורך-רוחב לחישוב זמני היום?:

@davidnead מעניין מה שאתה כותב. לא בדקתי בשנים האחרונות, אבל לפני 13 שנה בוודאות ככה היה כתוב בסוף הלוח, וגם לפני כ5 שנים למדתי שוב עניינים אלו בכולל ובדקתי שוב וכמעט בטוח שראיתי את זה שם.
היה כתוב על קרית ספר שמודד לפי מגדל המים, ובבני ברק לפי פונוביז'.

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

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

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

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

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

@שואף אמר במה הקוי אורך-רוחב לחישוב זמני היום?:

@davidnead אמר במה הקוי אורך-רוחב לחישוב זמני היום?:

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

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

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

@chv אמר במה הקוי אורך-רוחב לחישוב זמני היום?:

@צדיק-תמים לפעולה הזאת קוראים geolocation. כלומר למצוא מיקום גיאוגרפי (=קווי רוחב/אורך) על פי נתונים אחרים (לדוגמא שם עיר).

יש לזה חבילה טובה node-geocoder, היא תומכת בכמה מנועי geolocation - לחלקם יש עלויות כגון גוגל, שמצריך שימוש ב-GeoLocation API של גוגל, על ידי טוקן. אבל היא גם תומכת במנוע של openstreetmap שהוא חינמי.

אני מצרך עבורך קוד מוכן בדיוק עבור זה, שמצאתי אצלי בגינזך:

const NodeGeocoder = require('node-geocoder')
const geocoder = NodeGeocoder({ provider: 'openstreetmap' })

/**
 * get location and GeoLocation library city name for entered city name
 * @param {String} cityName - name of city to geolocate
 * @returns {Object} city - { success: boolean, latitude: latitude, longitude: longitude, cityname: name of located city }
 * @returns {Object} error - { success: boolean, error: error_message }
 */
async function getCityByName (cityName) {
  const locates = await geocoder.geocode(cityName) // check if the city exists
  if (!Array.isArray(locates) || !locates.length) {
    return { success: false, error: 'not a city' }
  } else {
    for (const locate of locates) {
      if (locate.countryCode !== 'IL') {
        continue
      }
      if (locate.city === cityName) {
        const city = { success: true, latitude: locate.latitude, longitude: locate.longitude, cityname: locate.city }
        return city
      }
    }
    return { success: false, error: 'not a city' }
  }
}

module.exports = getCityByName

תתאים אותו לצרכיך, בהצלחה!!

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

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

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

@גמליאל אמר במה הקוי אורך-רוחב לחישוב זמני היום?:

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

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

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

נסה פה:
https://www.google.com/search?gs_ssp=eJzj4tTP1TcwNDWONzVg9NK5vvD6zOvzrk-9Puf6DCC5QgFIzQQKTlEAis68vvz6CqDoQiBecn0GAEh_IZc&q=סימולטור+טיסה+מיקרוסופט&rlz=1C1GCEA_enIL965IL965&oq=אמולטור+טיס&aqs=chrome.7.69i57j0i13l6j46i13j0i13l2.5896j0j7&sourceid=chrome&ie=UTF-8

אם במקרה התכוונת אמולטור לאנדרואיד, אני ממליץ על blustack.
ואם יש לך ווינדוס11 - יש להם אמולטור מובנה שמתפקד מאוד נחמד (WSA).

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

@avramk אמר במחפש תוכנה שאפשר להדליק איתה מחשב מרחוק:

שלום רב, אשמח לקבל תוכנה חינמית שמדליקה מחשב ברשת מרוחקת.

@איש-ימיני אמר במחפש תוכנה שאפשר להדליק איתה מחשב מרחוק:

@avramk אתה יכול גם להגדיר בביוס שהמחשב יידלק אוטומטית ברגע שהוא מתחבר לחשמל

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

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

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

@yosefwitty אמר בהצגת חיווי מספר הודעות שלא נקראו בשורת המשימות של ווינדוס באפליקציה על WSA:

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

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

@chv אמר ביצירת פרויקט nodeJS שיבקש מהמשתמש קונפיג בהרצה הראשונה:

@davidnead אמר ביצירת פרויקט nodeJS שיבקש מהמשתמש קונפיג בהרצה הראשונה:

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

אלא מה? לחשוף אותו בקוד?

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

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

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

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

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