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

תגובה: המלצה לנטסטיק איכותי מאוד ואמין

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

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

אתה יכול להגיע למספר גם עם זה (להריץ בconsole)

alert(new URL(document.querySelector('iframe').src).searchParams.get('IE'))

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

@ששא כתב בשליחת מיילים מדומיין ללא אימות כל כתובת מחדש:

אני מתנצל אבל לא הצלחתי להבין

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

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

@ששא כתב בשליחת מיילים מדומיין ללא אימות כל כתובת מחדש:

שוב, אתה מדבר על ג'ימייל? שם צריך אימות על כל כתובת ושרשור

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

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

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

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

@ששא כתב בשליחת מיילים מדומיין ללא אימות כל כתובת מחדש:

על איזה אימות אתה מדבר?

אימות לשליחה, dkim, spf, dmarc. זה לא אימות ברמת הספק הספציפי.

@ששא כתב בשליחת מיילים מדומיין ללא אימות כל כתובת מחדש:

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

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

@ששא כתב בשליחת מיילים מדומיין ללא אימות כל כתובת מחדש:

הבנתי שבג'ימייל זה לא אפשרי (או שאולי אני טועה?)

בworkspace (לשעבר Gsuit) זה אפשרי.

@ששא כתב בשליחת מיילים מדומיין ללא אימות כל כתובת מחדש:

איפה זה אפשרי? כמובן בכמה שיותר זול, ושלא ייכנס לספאם

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

@יוס כתב במה הסוד להינצל מלהשלח לספאם:

של כתובת ה IP

כמו בקישור שצרפתי, וכמו שציינת בעצמך:

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

וזה נכון גם על הדומיין שלך.

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

זה עובד הפוך, צריך להיות עם וותק מסוים כדי לא להכנס לספאם. אין דרך אחרת, והחימום עוזר מניסיון. (אם הכל מוגדר נכון)
https://www.google.com/search?q=warming+up+an+ip+address

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

התוספת היחידה שעולה בדעתי שלא מגיעים אליה דרך גוגל היא זו:
https://github.com/ripienaar/free-for-dev
יש שם תוצאות גם בנושא הזה.

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

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

חסרון של סוג זה:

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

יתרונות:
זול בפער עצום מסוג מספר 2 להלן. בדרך כלל עם חיבור עם שירותים כמו cloudflare או letsencrypt כדי להשיג TLS וכדומה (בחינם).
יש לסייג שזה זול רק בשימוש עם מערכת הפעלה לינוקס (זה הנפוץ ב99% מהמקרים, אמנם יש אפשרות גם להתקין בכל מיני דרכים WIN לבד, אבל כשמראש הספק מאפשר שימוש בWIN בצורה חוקית, זה מעלה את המחיר בהרבה מאד, גם בגלל שזה בדרך כלל דורש מחשב חזק יותר, וגם בגלל שזה עולה כסף בנפרד).
ישנן עוד מעלות וחסרונות אבל זה הבסיס.

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

חסרונות:

1. יקר יותר בפער, למרות שגם בזה יש ספקים שנותנים בסיס בחינם מתוך ההנחה שכשתגדלו ותצרכו יותר תשלמו (או שתתרגלו לפלטפורמה וגם בפרויקטים גדולים יותר תשתמשו בזה, וזה מתחבר עם חסרון מספר 2 שהוא חסרון אדיר מימדים בעיני).
2. צריך לבנות מראש או להתאים את הפרויקט מקצה לקצה כדי להשתמש בשירות, לפחות בחלק מהתצורות של השירותים האלו (למשל בcloud functions) או לבחור במסגרת פיתוח שמתאימה את עצמה לזה (כמו nuxt.js בגירסה האחרונה), וככל שהשירות פחות מצריך פיתוח מראש בהתאמה לפלטפורמה, כך מחירו יעלה בהתאם.
3. הדרך להשתמש בשירות הזה, תמיד תבוא עם עוד שירותים בתשלום.. כמו אחסון של DB במקרה של functions כמו lambda.
   וזה מכיון שהשירות רק מפעיל את הקוד, כלומר הרעיון בבסיס השירות הוא שהם מספקים רק הפעלה של הקוד, אבל לא אחסון של נתונים או קבצים. זה לא מחשב שאתם מקבלים, זה שירות שמפעיל את הקוד שכתבתם, ואם השירות לא באוויר - הקוד לא באוויר.
   ההמשך של הרעיון הוא להשתמש בשירות אחר שמספק אחסון נתונים (למשל) ולחבר בין שני השירותים.
4. משאיר את המשתמש חסר ידע לחלוטין (הסימון של זה כחסרון הוא לטעמי האישי בלבד, ועל זה אפשר להוסיף שזה גם מצריך רכישת ידע - למידת השירות).

מעלות-הפוך מהחסרונות בסוג שירות מספר 1:

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

--

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

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

@aaaa כתב בסליקת אשראי נדרים פלוס ב API:

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

@חוקר כתב בסליקת אשראי נדרים פלוס ב API:

ברעיון יש להם

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

יש לcloudflare worker שמסוגל לשלוח מיילים, פרטים כאן.
טיפ:
לשנות לmimtext/browser, וכן זה לא פועל בworker של pages, אבל אפשר להוסיף route באתר שזה משויך אליו.

bigtable

https://stackoverflow.com/questions/362956 (מקור)

אגב:

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

2. בכל תוכנות מסדי הנתונים הנפוצות (שאני מכיר) יש אפשרות לאינדקסים.

1. אפשרי להצפין את הקובץ, עם מפתח סטטי שנמצא בתוך הexe.

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

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

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

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

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

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

מכיון שהעירו שהפונקציה לא תעבוד אחרי סוף עידן ה"תש", מצ"ב פונקציה משודרגת..
תודה ל@meir-lamdan שהביא לידיעתי את הפונקציה להמרת של ספירה בלש"ק.

const getHebDate2 = date => {
    const toHebCount = n => [...'ת'.repeat(Math.floor(n / 400)), ..."קרש"[Math.floor(n % 400 / 100) - 1] ?? [], ...n % 100 === 15 ? ['טו'] : n % 100 === 16 ? ['טז'] : [..."יכלמנסעפצ"[Math.floor(n % 100 / 10) - 1] ?? [], ..."אבגדהוזחט"[n % 10 - 1] ?? []]].toSpliced(-1,0, '"').join('').replace(/^"|"$/g, '').padEnd(2, "'");
    const getX = opt => Intl.DateTimeFormat('he-u-ca-hebrew', { [opt]: 'numeric' }).format(date || new Date());
    return [toHebCount(getX('day')), getX('month'), toHebCount(getX('year') % 1e3)].join(' ');
}

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

@ששא כתב בקבלת תאריך עברי של היום בשפת JS:

תמיד 8.

@ששא

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

getHebDate(new Date(2024,1,7))

החודש הוא 1 כי החודשים מתחילים מ-0 (לא ידוע לי מדוע).

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