@yoel3 כתב במספר חייגני PPPOE על סיב בזק / IBC:
@Shmuel754
זה המשחק?
בוודאות?
כן, זה גם מופיע בתגובה של הפוסט שהבאת בתחילת השרשור.
אגב, זה גם מסביר את העובדה שבמודם בזק, יש לבזק גישה למודם גם באם אין חיוג לספק, מאחר והמודם מוגדר בנוסף לחייג גם למערכות בזק.
הבעיה כיום, שאי אפשר להשיג יוזרים בנפרד רק בצירוף תשתית.
ועוד נקודה, יוזר של בזק מתאים רק לקו של ההתקנה, אי אפשר לחייג עם היוזר בקו בזק אחר.
אם אתה מחייג לספק בזק, לא ניתן לחייג לספק נוסף.
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
כי ברגע שהוא רוצה להוציא התראה צינתוק למתעניין, התהליך של פלטור בזמן אמת הופך למשימה שלו שהוא צריך לבצע, ולכן הוא מניע את התהליך בחיפוש ורישום, תהליך חד-פעמי, שהמשך המתקשר רק שולף נתונים.
זה לא תהליך חד פעמי, זה מתעדכן בכל הוספת/שינוי/מחיקה של מודעה. אולי לא הבנתי אותך נכון, מה מטרת הטבלה הזאת? מעין לוג כדי שנוכל לראות בעתיד איזה התראות נשלחו ללקוח?
אני מסתכל על זה כך,
נכס, כוללים נתונים שאינם משתנים, לא ישוב ורחוב ולא חדרים ולא בעלים, אם זה משתנה מדובר במודעה/נכס אחר מה שמשתנה זה המחיר, ותאריך הפרסום, וזה נתונים שיש לנהל, ברור שזה מקושר למודעה וזה טבלת הפרסומים, כשאתה רושם שינוי של המודעה הכוונה כנראה לנתוני הפרסום ולא לנתוני הבסיס.
כשהנתונים לא רלוונטים, אתה לא מוחק אותם אבל זה הופך לסוג של היסטוריה, ואם תרצה תקרא לזה לוג.
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
נרשם למעלה שהוא מעדכן את תאריך המודעה בהתאם לתאריך שהוא רוצה לפרסם,
והלוג של מחר זה הנתונים של היום, וכל הנושא זה המבט מלמעלה לראות את כל ההיסטוריה בסדר יורד, מבלי לנהל לוג נפרד.אני לא מסכים, נתונים והסטוריה זה לא אותו דבר, בתפקוד השוטף של האפליקציה אין עניין להתעסק עם ההסטוריה הסטוריה מיועדת למקרי קצה שתיארת אותם יפה, שמישהו רוצה לדעת מה היה קודם ומה אחר כך, לזה מספיק טבלאות נפרדות של הסטוריה או audit log, לא הגיוני בגלל זה לסרבל את כל המבנה של הנתונים
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אין כאן כפילות של מידע, כשאתה מפרסם נכסים עבור לקוחות (דהיינו מתעניינים בפרסומים), יש לך ענף חדש לניהול שזה לקוח מתעניין איזה מידע קיבל, מתי, ולמה, זה מידע שנוצר מסינון דינמי של המידע (כל רגע נתון) למידע סטטי מול הלקוח.
לא ענית למה זה צריך להיות בטבלה סטטית שמתעדכנת על ידי תהליך רקע ולא פלטור בזמן אמת
כי ברגע שהוא רוצה להוציא התראה צינתוק למתעניין, התהליך של פלטור בזמן אמת הופך למשימה שלו שהוא צריך לבצע, ולכן הוא מניע את התהליך בחיפוש ורישום, תהליך חד-פעמי, שהמשך המתקשר רק שולף נתונים.
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
ולמה כל זה חשוב, במבט לעתיד, כל מה שאתה עושה היום עבור לקוחות תרתי משמע גם מפרסמים וגם מתעניינים, אתה צריך להיות ערוך עם היסטוריה של הנתונים. לדוגמא, בעוד שנה יפנה אליך מתעניין שראה את הפרסום ויבקש אישור לבי"ד בד"ת שיש לו עם הצד השני, ויבקש אסמכתא שבתאריך הנ"ל זה פורסם בנתון זה, או שהמפרסם יתלונן אליך למה פרסמת ב-3,000 כשהמחיר שהוא רוצה זה 3500, אם תצליח להוכיח שזה מה שהוא הקיש בIVR (הרי לא רלוונטי הקלטת שיחה של ההקשות), ניצלת. או שמחר יקפוץ עליך מאן דהו ויטען שאתה מעתיק את המאגר שלו, אם תצליח להוכיח שקיבלת את הנתון יום לפניו מקור זה וזה ובגלל תאריך הקליטה במאגר שלך שאינו משתנה, כדין רשומה מוסדית, ניצלת.
אבל את כל זה אפשר לעשות גם בלי להפריד לשכבת נכסים ושכבת מודעות, אף אחד לא אמר למחוק מהדאטהבייס לגמרי את המודעה שנהפכה ללא רלוונטית או את הלוגים שלה
מה שתיארת זה audit log זה לא אמור להשפיע על מבנה הנתונים
נרשם למעלה שהוא מעדכן את תאריך המודעה בהתאם לתאריך שהוא רוצה לפרסם,
והלוג של מחר זה הנתונים של היום, וכל הנושא זה המבט מלמעלה לראות את כל ההיסטוריה בסדר יורד, מבלי לנהל לוג נפרד.
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
בשביל מה טבלה סטטית נוספת שמתוחזקת על ידי לולאת הסינון? אתה יוצר כפילות מיותרת של מידע
לגבי הפרדת פרסומים מנכסים זה כיוון מעניין אבל לדעתי לא צריך להגיע לזה. בגדול זה לוח מודעות דיגיטלי, לא מערכת ניהול נכסים, לא בטוח בכלל שאת אותו נכס יפרסם אותו אדם כל פעם, לא אמור להיות יישות נפרדת של נכס לדעתי
אין כאן כפילות של מידע, כשאתה מפרסם נכסים עבור לקוחות (דהיינו מתעניינים בפרסומים), יש לך ענף חדש לניהול שזה לקוח מתעניין איזה מידע קיבל, מתי, ולמה, זה מידע שנוצר מסינון דינמי של המידע (כל רגע נתון) למידע סטטי מול הלקוח.
וכך לגבי הפרדת פרסומים מנכסים, יש כן מקרים שאותו בעל נכס מפרסם מחדש אותו נכס, כמו בשכירות כל שנה מחדש, שהנכס אותו נכס אותם פרטים אותם בעלים, אבל הושכר לפני שנה וכעת חזר לשוק.
ולמה כל זה חשוב, במבט לעתיד, כל מה שאתה עושה היום עבור לקוחות תרתי משמע גם מפרסמים וגם מתעניינים, אתה צריך להיות ערוך עם היסטוריה של הנתונים. לדוגמא, בעוד שנה יפנה אליך מתעניין שראה את הפרסום ויבקש אישור לבי"ד בד"ת שיש לו עם הצד השני, ויבקש אסמכתא שבתאריך הנ"ל זה פורסם בנתון זה, או שהמפרסם יתלונן אליך למה פרסמת ב-3,000 כשהמחיר שהוא רוצה זה 3500, אם תצליח להוכיח שזה מה שהוא הקיש בIVR (הרי לא רלוונטי הקלטת שיחה של ההקשות), ניצלת. או שמחר יקפוץ עליך מאן דהו ויטען שאתה מעתיק את המאגר שלו, אם תצליח להוכיח שקיבלת את הנתון יום לפניו מקור זה וזה ובגלל תאריך הקליטה במאגר שלך שאינו משתנה, כדין רשומה מוסדית, ניצלת.
במילים אחרות, כל נתון שנראה לא רלוונטי כיום, הופך מאוד רלוונטי בעתיד, כשאתה נצרך לזה.
מה גם שכל הDB שלו לא יקרוס מרוב חומר, מדובר בעשרות אלפים בודדים של חומר של כמה גיגות לכל היותר, ולא צורך של גישה מרובה בכל רגע נתון.
@eido
לפי איך שאני מבין אתה צריך כמה דברים, יתכן שחלקם יש לך ואתה עובד כך, נפרט
תאריך פרסום - בכל מודעה שינוי סטטוס של מודעה אמור להיות תאריך פרסום, שזה אומר שההודעה הזו בתוקף מאותו תאריך.
שינוי סטטוס אומר גם ירידת מחיר מ3000 ל2800 לדוגמא, שינוי כזה יש לסדר מחדש ללקוח מאחר ויתכן שבמחיר 3000 זה לא רלוונטי אבל ב2800 יש על מה לדבר, אתה יכול להוסיף נתון שהמחיר בעבר היה גבוה יותר, וכן פרסום של שכירות משנה קודמת שכרגע הוא שוב בשוק, אמור להיות מוגדר חדש למרות שאותו לקוח שמע בעבר.
הסינון - לולאת הסינון אמור לקחת את כל הפרסומים הרלבנטיים (מינוס X ימים אחורה), ולפתוח רשומה טבלה נוספת הכולל זיהוי לקוח, זיהוי פרסום, תאריך פרסום, תאריך שמיעה.
בהשמעה - אתה משמיע רק את את מה שלא שמע, בכל העברת רשומה בIVR אתה מעדכן תאריך שמיעה.
הבעיה שאתה מציג שבעת החזרת הסינון אחרי שנמחק הסינון, אתה אמור להוסיף רק את הפרסומים הרלוונטיות (מינוס X ימים אחורה) ולא אמור להוסיף את כל הקודמים שהם פחות רלוונטים כרגע.
במשפט קצר, אתה אמור לסנן פרסומים ולא לסנן נכסים, לכל נכס יש הרבה פרסומים בהמשך הזמן.
לגבי מהירות הסינון, כל הDB שלך בגדול הוא 50 אלף רשומות שמבוסס על מספרים אם הוא מאונדקס נכון, אין בעיה של זמן סינון, גם את הלולאה של יצירת רשימות ההשמעה ללקוח, אתה יכול לעשות כטריגר בעת הוספת פרסום ואז שירוץ על כל השורות המכילות את התנאי של הנכס ומתאים לסינון ולהכניס לרשימה, או שפעם בכמה דקות תפעיל לולאה כזו על כל הפרסומים החדשים.
כשהלקוח מתקשר אמור להישלף מה DB רק את הפרסומים המוכנים בשבילו בטבלה ולא יצירה מחדש של סינון דימני.
@OdedDvir מדוע שלא תשתמש בנדרים פלוס, יש ביצוע אוטומטי של הו"ק אין צורך בשידור, הם משדרים. רק להכניס את נתוני התורמים והכל נוסע.
@Mordechay איזה ראוטר יש לך?
האם מוגדר עליו סוג של NAT?
בדוגמא שהבאת מופיע שם מאת וגם בסוגריים אובייקט,
תעשה חיפוש לפי השם ותראה אם כל המיילים של השולח הזה מופיע אובייקט, אותם תעביר.
ניסית לבדוק בתווית אחרת כמו אשפה באם זה מוצג נכון?
@ek0583232948 כתב בGMAIL לא מציג לי כתובת שולח:
@Shmuel754 כתב בGMAIL לא מציג לי כתובת שולח:
נסה להעביר את כל המיילים של השולח הזה לתווית אחרת ותוציא את זה מתווית דואר נכנס, לפני זה אתה גם יכול לבדוק באם מיילים מאשפה או מה שלא מוצג בדואר נכנס מוצגים נכון.
אבל זה קורה בכל השולחים
כנראה המיילים הספציפיים האלו של השולח עם האובייקט משבשים את גימייל, לכן תעביר אותם לתווית אחרת ותוציא מנכנס, ואז תבדוק מה קורה בנכנס. והאם הסתדר. אולי אפי' כדאי שבשלב זה תכנס מדפדפן אחר או מגלישה בסתר כדי שכל הדף יתרענן.
@ek0583232948
מה שלא מוצג זה כתובת המייל של השולח, מוצג שם איזה אובייקט שהשולח הכניס וגימייל לא מציג אותו אבל מציג שיש אובייקט.
נסה לבדוק בהצגת המקור מהתפריט השמאלי, אולי תגלה שם הסבר.
נסה להעביר את כל המיילים של השולח הזה לתווית אחרת ותוציא את זה מתווית דואר נכנס, לפני זה אתה גם יכול לבדוק באם מיילים מאשפה או מה שלא מוצג בדואר נכנס מוצגים נכון.
יתכן שהמיילים של השולח הספציפי הזה עם האובייקט משבשים את התצוגה של גימייל ולכן זה משפיע על כל המיילים.
@dovid כתב במרחק נסיעה לרב קו, בעת החלפת רכבת:
@Shmuel754 תודה! יש לך אסמכתא כל שהיא?
ניתן לראות במחשבון בעמוד הנ"ל שהמרחק בין תל אביב למודיעין הוא כ27 ק"מ וממודיעין לירושלים 22 ק"מ, ונסיעה מתל אביב לירושלים הוא 49 ק"מ.
בנוסף, תיקוף יציאה וכניסה ברכבת הוא לא כזה מהיר וקל, קיים מרחק הליכה עד השערים בכניסת התחנה שלאחר הבידוק ולרוב יש עומסים, כך שבוודאי אתה לא יכול להמשיך באותו רכבת, בניגוד לאוטובוס שאתה ניגש לנהג ומתקף שוב (ולא כל פעם זה מצליח תלוי בתוכנה).
@dovid נסיעה פרושו נסיעה מתיקוף כניסה ועד תיקוף יציאה, אם אתה לא מתקף ב40 ק"מ, יש לך נסיעה ארוכה של הדירוג הבא.
@יעקב2
דור 5 דורש קירבה יתר קרובה לאנטנה, הרדיוס של קליטה בדור 5 קטנה יותר מדור 4, אנטנה חיצונית יעזור לו יותר מאשר דור 5, אם ימקם את האנטנה על הגג או במיקום פתוח יותר ולא בתוך מבנה יש לו סיכוי לקבל קליטה יותר טובה וחזקה יותר.
ישנם רצועות תדרים לקליטה בתוך מבנים ויש רצועת תדרים לקליטה חיצונית, כבר נתקלתי במיקום שבמפלס קרקע בתוך מבנה לא היה קליטה סבירה 2 פסים, ולאחר שמיקמתי את האנטנה על הגג במפלס 3 קיבלתי פול קליטה (בקליטה B28 שזה תדר למבנים וחזק יותר כשהמרחק מהאנטנה הוא 1.2 ק"מ)
@shraga במודם שלי רשום על אנטנה אחת main antenna - ולפי מה שקראתי זה משמש לדור 4 והשני סוג של גיבוי/תוספת.
בבדיקה שעשיתי באם חיברתי 2 אנטנות קיבלתי נתונים טובים יותר מחיבור אנטנה אחת., כך שעדיף לחבר 2 אנטנות.
@shraga
הלינק שאני רכשתי כרגע מוצר לא זמין, וזה המוצר https://he.aliexpress.com/item/1005004592564303.html
וחיבורי TS9 ל SMA לא רכשתי אבל אפשר למצוא בעלי אקספרס ts9 to sma
@shraga אני משתמש באנטנות חיצוניות בחיבור SMA ישנן מגשרי חיבורים של TS9 לSMA, ואז אתה יכול לחבר אנטנה מסוג זה שמתאים לLTE.
מתוך ניסיון אנטנה חיצונית משפר מאוד את הקליטה במקומות בעייתים, ואפשר גם להוסיף חוט ארוך יותר לגג המבנה לדוגמא.
בנוסף מומלץ מאוד שיהיה אופציה לבחירה של סוגי התדרים, דהיינו לפעמים פס תדר B1 או אחר נותנים לך קליטה נמוכה יותר אבל אם אתה מנטרל את התדר והוא מתחבר לפס תדר אחר הקליטה יותר טובה. כל זה באם מדובר במיקום קבוע, במיקומים ניידים עדיף לתת למודם לבחור לבד.
@telekesher איך אתה רוצה שניכנס לאתר?
להירשם פלוס ת.ז. ומה עוד אנו אמורים לספק, על שירות שאנו לא בטוחים שרלוונטי לנו?
תספק בבקשה שם משתמש וסיסמה לכניסה לאתר, כדי שנוכל להיכנס להתרשם.
אינטרס שלך, לא שלנו.
אם אתה רוצה שנתרשם ומשוב, ספק בבקשה משתמש DEMO ללא צורך להירשם.
@יוס DomainKey (DKIM) הגדרת?
