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

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

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

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

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

@aaron כתב באיך לממש תהליך פיתוח ודילוור גמיש ומהיר בלי להיות מומחה לתשתיות\לעבוד קשה:

docker context use develop

תודה, לא הכרתי את זה.

@dovid כתב באיך לממש תהליך פיתוח ודילוור גמיש ומהיר בלי להיות מומחה לתשתיות\לעבוד קשה:

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

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

@aaron כתב באיך לממש תהליך פיתוח ודילוור גמיש ומהיר בלי להיות מומחה לתשתיות\לעבוד קשה:

לשמור שינוים בשרת GIT זה פרקטיקה מומלצת בכל מקרה.

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

אני מחפש את הדרך הנכונה או הכי פחות כואבת, לפתח\לתחזק אפליקציית FS שכל כולה באחריותי (נניח לצורך הדוגמה שהיא מבוססת vue - node/express - mongo), ולדלוור את השינויים לשרת (דרך SSH) בלי בלאגן (שיהיה כזה npm run deploy.. ).
לצורך הפשטות נניח שניהול הגרסאות הוא בGIT לוקלי, ואין הבדל בין המערכת שלי לזו שבשרת. כמובן שהמציאות הרבה יותר מורכבת, וגם docker מעורב (אם זה רק עוזר - הכי טוב).
כרגע התהליך שישנו מורכב מהרצה של כמה וכמה פקודות, בסביבת הפיתוח ,וגם בשרת, אשמח להצעות ייעול (לפרוייקטים עתידיים בעיקר).

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

הדרך המקובלת לשליחה באמצעות nodejs (דרך שרת שעושה את השליחה בפועל) היא אחת מה-2: SMTP (התחברות לשרת כמו שתוכנת לקוח מייל מתחברת) ו-API.
למעשה אפשר גם לשלוח ישירות עם nodejs (ללא צורך בשרת, או במקום שרת, וללא צורך בהתחברות).

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

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

שרת מיילים ששולח או שמקבל?

לשולח - כמה טיפים שיעזרו:
בדוק שיש לו אפשרות להוציא תקשורת מפורט 25.. (תיקון טעות: אל פורט 25).
אם אין לדומיין שבשמו אתה שולח רשומת ptr, גוגל ידחו שליחה אליהם עוד בשלב המגעים עם השרת שלהם.
כדאי לדאוג להגדיר spf, dkim, dmark כראוי (רשומת TXT עם הגדרות הIP/דומיין שמורשה לשלוח וכדו', מפתח פומבי שמור ברשומתTXT בתוך סאב דומיין ייחודי וחתימה של המייל עם המפתח הפרטי, רשומת TXT עם הגדרות מי מקבל דיווח על הפרה של הרשאות, בהתאמה).
זה הבסיס, יש עוד המון טריקים שיכולים לעזור בהרבה כיוונים.

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

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

@Shmuel754 כתב בשיתוף! תתקשר לארה"ב חינם וללא הגבלה:

בשיחות בינלאומיות חיוב המתקשר הוא לפי זיהוי שיחה יוצאת

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

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

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

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

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

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

@שואף

https://www.gov.il/he/departments/news/cpfta_dncapi

@ענן
נראה שהאתר לא פועל תקין בנטפרי
זה JS שיעבוד, צריך להוסיף טיפול אסינכרוני או then.

fetch(URL, {method: 'POST', headers:{'token': 'ADSACRERRECTRETR', 'content-type': 'application/json'}, body:JSON.stringify({user: 'natn456', netonim:{}})})

הקוד הזה יותר הגיוני בCURL

curl URL -H 'token: ADSACRERRECTRETR' -d '{"user": natn456, "netonim":{}}'

אולי להוסיף פירוט באיזה חלק הקושי
לעתים צריך להוסיף
'content-type': 'application/json'
תלוי באפליקציה ובסוג הbody

@nigun
עיין בפוסט הזה
https://tchumim.com/post/141786

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

באמת כאן @OdedDvir כתב מאד יפה בענין, עם פירוט על כמה זוויות.

לפי המבט שלו מפתח מתחיל ייקח יותר, כי יהיה לו יותר קשה לתת תמיכה..

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

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

אגב, הפירצות האלו בטיעונים שלי, גלויות וניסיתי לסתום אותם.

ואם מישהו מנצל את זה שהלקוח לא יודע מה השווי בשוק, זה נחשב אונאה.

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

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

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

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

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

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

---

היו שני חלקים:

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

---

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

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

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

---

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

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

---

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

---

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

@one1010
היתה הצעה לחשב אם זה שכר חודשי.
היתה הצעה לחשב את שווי העבודה ביחס לשווי המוצר בשוק.
כתבו שלתת ללקוח הרגשה שאתה טוב, זה הטעיה. וכדומה.

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

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

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

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

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

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

@אבי_770 אמר בכמה כדאי לקחת על פיתוח?:

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

כמה כדאי לקחת על פיתוח?

@אבי_770

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

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

עוד דבר חשוב: אל תקרא את שאר התגובות וההצעות והרעיונות באשכול הזה.
בהצלחות!

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

@חגי אמר בהתחברות לheroku cli בשרת לינוקס:

יצירת מפתח SSH

בנוסף, לבעיה שתוארה כאן אין צורך להתקין את הCLI של heroku, מספיק GIT , ו- clone מהURL של הremote של heroku.

git מביא תועלת גדולה יותר אם משתמשים בו בצורה המקובלת (כותב כדי להזכיר לעצמי..) שהmain-master מחזיק את הprod.

@dovid אמר בהתחברות לheroku cli בשרת לינוקס:

יש להם ייתרון?

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

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

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