@eido כתב בעזרה בתכנון מבנה מערכת:
כי אם מספר הטלפון זה הפרט היחיד בשביל לשנות מספר טלפון, כל אחד יכול לעשות את זה... גם אם הוא לא בעל הפלאפון...
שוב, עם אימות בקוד בשיחה נכנסת/צינתוק, כמו שיש בבנק ובכל מקום שעובדים עם זיהוי טלפוני
@eido כתב בעזרה בתכנון מבנה מערכת:
כי אם מספר הטלפון זה הפרט היחיד בשביל לשנות מספר טלפון, כל אחד יכול לעשות את זה... גם אם הוא לא בעל הפלאפון...
שוב, עם אימות בקוד בשיחה נכנסת/צינתוק, כמו שיש בבנק ובכל מקום שעובדים עם זיהוי טלפוני
@eido ולמה עדכון מספר טלפון אי אפשר לעשות עם אימות מספר נוכחי?
@eido כתב בעזרה בתכנון מבנה מערכת:
לגופו של ענין, אין הצעות לדברים נצרכים?
תיארת דרישות פונקציונליות מאוד מצומצמות, עם הספריה מול מודול API של ימות זה אמור להיות כמה עשרות שורות קוד בלבד
קשה למצוא בשר בכזה דבר...
@eido אני לא חושב שהגיוני לדרוש מהלקוח לזכור לתמיד 4 ספרות של כרטיס שאיתו שילם כדי לגשת למוצר שקנה
אם אתה רוצה לאמת את הזיהוי של המספר טלפון אתה יכול לשלוח קוד בשיחה נכנסת
למה צריך את ה4 ספרות כדי לזהות את הלקוח?
למה לא מספיק מספר טלפון (עם קוד אימות בצינתוק נכנס אם אתה חושש לזיוף זיהוי, חשש מוגזם לדעתי)?
אני משער שהמספרים פייק?
נשמע אתר די פשוט שעדיף כבר לבנות מאפס מאשר לטבוע בכל הג'אנק הזה
@eido כתב בדפדפן מראה שהשרת לא מאובטח למרות שיש תעודה בתוקף:
הוא עושה fetch לקבצי PHP שנמצאים בתיקיה אחרת.
זה לא תקין
זה בהחלט שרת חזק, השאלה מה רץ על השרת...
@eido כתב בburte force על השרת שלי:
אני משתמש רק בתעודת אבטחה, אבל האמת עכשיו זה חריג, זה לא מפסיק לרגע, קשה להתחבר לשרת שלי, כל דבר פשוט לוקח לו זמן.
אני מתקשה להאמין שזה בגלל נסיונות התחברות
אגב, חשוב לא רק שאתה תתחבר עם תעודה אלא שהאופציה להתחבר עם סיסמה תהיה מושבתת בקובץ קונפיג של sshd
@חגי אין מענק עבודה למי שלא א. מעל גיל 21 ב. הורה לילד
@אבי_1 כתב בבחור ישיבה שיעבוד במשק בית פעם בשבוע כדי להוריד מדמי הביטוח לאומי?:
בן כמעט בן 19 בחור ישיבה
@NH.LOCAL כתב בבירור על מערכת סליקת אשראי מתאימה לאתר עם מודל מנויים:
מה ההשלכות עלי אם אני פותח תיק עכשיו או נניח בתחילת השנה הבאה?
אני יודע שאפשר לפתוח עסק עם דיווח רטרואקטיבי שלושה חודשים אחורה. השאלה איך החודשים האחרונים יחושבו בהתחשב בזה שאני מתנגש בדיוק עם סיום שנת הכספים
למה לא לפתוח עכשיו?
@eido כתב בבירור על מערכת סליקת אשראי מתאימה לאתר עם מודל מנויים:
התכוונתי שבשנה הראשונה מדווחים כל חודש (וגם משלמים אם צריך) ושנה אח"כ כבר לא צריך (כך אצלי לפחות).
אני לא יודע מתי פתחת, אבל כנראה לפני רפורמת עסק זעיר
ההליך היום הרבה יותר פשוט, תיאום מס לפני סוף שנה ודיווח ותשלום מס בתחילת השנה שאחריה, שניהם בממשקים סבירים (יחסית לרשות המיסים) ולא טפסי ענק מסובכים
וזהו
@eido כן, זה עקרון חשוב מאוד שחוסך הרבה באגים וסרבול
@eido המידע מי שמע הוא מידע שאתה צריך אותו. הוא לא תוצר של פילטור, ולכן הגיוני לשמור אותו. המידע "המודעה הזאת מתאימה למשתמש הזה כי הוא לא ראה אותה עדיין ויש לו קמפיין מתאים" הוא תוצר של שאילתה ויכול להשתנות בכל רגע ולכן לא שומרים אותו בצורה סטטית
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
חוסכת מהמאזין זמן ריצה כמו קאש שמושכים ממנו את המודעות
אם תהיה לך בעיית איטיות אחרי אינדקסים מתאימים נדבר, לא נראה לי סביר שתגיע לזה
@eido נראה לי שכתבתי כבר את כל ההסברים, זה נהיה דיון מעגלי.
@eido אם אין לך אפשרות לעמודת ARRAY ממש, עדיף עם טבלה נפרדת כדי שתוכל לעשות אינדקסים
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
כי ברגע שהוא רוצה להוציא התראה צינתוק למתעניין, התהליך של פלטור בזמן אמת הופך למשימה שלו שהוא צריך לבצע, ולכן הוא מניע את התהליך בחיפוש ורישום, תהליך חד-פעמי, שהמשך המתקשר רק שולף נתונים.
זה לא תהליך חד פעמי, זה מתעדכן בכל הוספת/שינוי/מחיקה של מודעה. אולי לא הבנתי אותך נכון, מה מטרת הטבלה הזאת?
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
נרשם למעלה שהוא מעדכן את תאריך המודעה בהתאם לתאריך שהוא רוצה לפרסם,
והלוג של מחר זה הנתונים של היום, וכל הנושא זה המבט מלמעלה לראות את כל ההיסטוריה בסדר יורד, מבלי לנהל לוג נפרד.
אני לא מסכים, נתונים והסטוריה זה לא אותו דבר, בתפקוד השוטף של האפליקציה אין עניין להתעסק עם ההסטוריה הסטוריה מיועדת למקרי קצה שתיארת אותם יפה, שמישהו רוצה לדעת מה היה קודם ומה אחר כך, לזה מספיק טבלאות נפרדות של הסטוריה או audit log, לא הגיוני בגלל זה לסרבל את כל המבנה של הנתונים
בכל מקרה, לגבי ההפרדה לנכסים ומודעות, אני לא מתנגד לזה נחרצות,
רק לטבלת ה"מודעות לצפיית הלקוח" שמשכפלת מידע שמשתנה כל רגע ואמורה להיות רק שאילתה בזמן אמת